ENISA: Europees Agentschap voor netwerk- en informatiebeveiliging

Het Europees Agentschap voor netwerk- en informatiebeveiliging (ENISA) is een centrum voor netwerk- en informatie-expertise. Het werkt nauw samen met de EU-lidstaten en de particuliere sector om richtlijnen en aanbevelingen te geven over effectieve cyberbeveiligingspraktijken. ENISA helpt ook bij de ontwikkeling en uitvoering van EU-beleid en -wetten met betrekking tot nationale informatiebeveiliging.

Het ENISA Cloud Computing Information Assurance Framework (IAF) is een reeks garantiecriteria die organisaties kunnen bespreken met cloudserviceproviders (CSP's) om ervoor te zorgen dat ze voldoende bescherming hebben voor klantgegevens. De IAF is bedoeld om het risico van de implementatie van de cloud te beoordelen en de garantielast voor CSP's te verminderen.

Atlassian sluit zich aan bij de IAF door Atlassian zich te houden aan de Cloud Security Alliance (CSA) Cloud Control Matrix (CCM), die CCM-domeinen en -controles in kaart brengt volgens de IAF-garantiecriteria en certificering volgens ISO 27001.

Atlassian handhaaft de volgende op de CCM gebaseerde garanties:

• CSA Star 1-zelfbeoordeling

De volgende richtlijnen bevatten garantiecriteria om organisaties te helpen bij het kiezen van een cloudserviceprovider. Als je vragen hebt over specifieke gegevens, neem dan contact op met ons Enterprise Sales Team op https://www.atlassian.com/enterprise/contact?formType=product-features.

6.01

De meeste vragen met betrekking tot personeel zullen vergelijkbaar zijn met de vragen die je zou stellen aan je eigen IT-personeel of aan ander personeel dat zich met je IT bezighoudt. Zoals bij de meeste beoordelingen is er een balans tussen risico en kosten.

6.01. (a)

Welk beleid en welke procedures hanteer je als je IT-beheerders of anderen met toegang tot het systeem aanneemt? Deze zijn onder andere:

• Controles voorafgaand aan de indiensttreding (identiteit, nationaliteit of status, arbeidsverleden en referenties, strafrechtelijke veroordelingen en doorlichting (voor hoger personeel in functies met hoge voorrechten)).

In overeenstemming met de wetten van hun woonplaats moeten nieuwe Atlassians een antecedentenonderzoek ondergaan. In overeenstemming met de wetgeving van hun woonplaats laten nieuw aangeworven werknemers als gevolg van een acquisitie na de acquisitiedatum een antecedentenonderzoek uitvoeren. Bij alle nieuwe werknemers en onafhankelijke contractanten wordt een strafrechtelijke controle uitgevoerd. Er worden ook opleidingsverificatie, tewerkstellingsverificatie of kredietcontroles toegevoegd als de functie of het niveau van de functie dat vereist. We voeren volledige antecedentenonderzoeken uit voor leidinggevende en boekhoudkundige functies.

6.01. (b)

Geldt er een ander beleid, afhankelijk van waar de gegevens worden opgeslagen of toepassingen worden uitgevoerd?

• Het aanwervingsbeleid in de ene regio kan bijvoorbeeld anders zijn dan in een andere.
• De praktijken moeten in alle regio's consistent zijn.
• Het kan zijn dat gevoelige gegevens in een bepaalde regio worden opgeslagen met geschikt personeel.

Atlassian hanteert beperkingen voor het personeel dat toegang nodig heeft tot onze systemen, applicaties en infrastructuur voor hun functie en verantwoordelijkheden, op basis van de minste bevoegdheden, en dit wordt afgedwongen door middel van onze authenticatieprocessen. Alle toegang is via geverifieerde sessies en gebaseerd op vastgestelde rechten.

Alle niveau 1-systemen worden beheerd via de centrale eenmalige aanmelding (SSO) en mapoplossing van Atlassian. Gebruikers krijgen de juiste toegangsrechten op basis van deze profielen, aangestuurd via de workflow van ons HR-beheersysteem. Atlassian maakt gebruik van MFA voor toegang tot alle niveau 1-systemen. We hebben tweevoudige authenticatie mogelijk gemaakt voor de hypervisorbeheerconsole en de AWS-API, en geven een dagelijks auditrapport uit over alle toegang tot de hypervisorbeheerfuncties. De toegangslijsten voor de hypervisorbeheerconsole en de AWS-API worden elk kwartaal herzien. We zorgen ook voor een synchronisatie van elke 8 uur tussen ons HR-systeem en ons identiteitsarchief.

In het algemeen worden controles met betrekking tot toegangscontrole behandeld in het Toegangsbeheerbeleid, waarvan een uittreksel hier beschikbaar is: https://www.atlassian.com/trust

6.01. (c)

Welk onderwijsprogramma op het gebied van beveiliging voer je voor alle medewerkers uit?

Atlassian biedt informatiebeveiligingstrainingen als onderdeel van een onboardingtraining ('dag 1') voor nieuwe medewerkers en doorlopend voor al het personeel.

Naast deze algemene informatiebeveiligingstraining worden onze ontwikkelaars gerichter getraind op het gebied van veilig coderen. Deze wordt ondersteund door ons programma voor geïntegreerde beveiligingsingenieurs.

We geven ook doorlopende actuele trainingen over malware, phishing en andere beveiligingsproblemen. Ga voor meer informatie naar: https://www.atlassian.com/trust/security/security-practices#security-awareness-training

We houden formele records bij over de voltooiing van de interne opleiding van personeel. Werknemers moeten de gedragscode jaarlijks erkennen en opnieuw bevestigen. Dit beleid is bedoeld voor alle werknemers. De vereisten op het gebied van veiligheidsbewustzijn, vertrouwelijkheid en privacy worden gepresenteerd in hun dagelijkse trainingen en zijn beschikbaar voor alle werknemers in Confluence.

6.01. (d)

Is er een proces van continue evaluatie?

• Hoe vaak komt dit voor?
• Nog meer interviews.
• Beoordelingen van beveiligingstoegang en privileges.
• Beoordelingen van beleid en procedures.

Atlassian heeft de SOC2-, ISO27001- en ISO27018-certificeringen behaald voor onze cloudservices. We voeren minstens jaarlijks zowel interne audits/audits over gereedheid als externe audits uit. Atlassian is ISO-gecertificeerd voor een aantal producten. Dit vereist regelmatige risicobeoordelingen en beoordelingen van datapraktijken.

Ga voor meer informatie naar: https://www.atlassian.com/trust/compliance. Klanten moeten op deze site regelmatig updates van onze conformiteitscertificaten en -rapporten downloaden en lezen.

Atlassian heeft een gedocumenteerd beleidskader met ons veiligheidsbeleid als belangrijkste beleid. Ons Policy Management Program (PMP) is gedefinieerd en omvat eigendom, beschikbaarheid en beoordelingscyclus, en schetst onze algemene doelstellingen. Onze beleidsregels worden minstens jaarlijks herzien en goedgekeurd door het senior management. Meer informatie over ons PMP is te vinden op: https://www.atlassian.com/trust/security/security-management-program

We hebben ook uittreksels gepubliceerd van elk van onze belangrijke beleidsmaatregelen met de tl:dr, die te vinden zijn op: https://www.atlassian.com/trust/security/ismp-policies

Alle systemen en projecten worden onderworpen aan een impactbeoordeling met betrekking tot persoonlijk identificeerbare informatie.

Onze overeenkomsten voor derden van Atlassian bevatten beveiligings- en privacybepalingen, voor zover van toepassing. Nieuwe leveranciers bij Atlassian moeten in onze contracten instemmen met ons privacy- en veiligheidsbeleid. Onze juridische teams en inkoopteams beoordelen contracten, SLA's en het interne beleid van leveranciers om de risico's in verband met beveiliging, beschikbaarheid en vertrouwelijkheid te beheersen. Het Enterprise Risk Management (ERM)-programma van Atlassian voert jaarlijks een risicobeoordeling uit waarin de waarschijnlijkheid en impact voor alle risicocategorieën zijn opgenomen en die is afgestemd op het COSO-risicomodel. We voeren indien nodig ook functionele risicobeoordelingen uit op basis van het risicoprofiel. Risicobeoordelingen worden herzien als onderdeel van de hernieuwing van het beleid en op elk moment dat de relatie met de leverancier aanzienlijk verandert.

6.02.

De volgende vragen zijn van toepassing wanneer de cloudprovider voor bepaalde activiteiten die essentieel zijn voor de beveiliging van de operatie onderaanneming aan derden geeft (bijvoorbeeld een SaaS-provider die het onderliggende platform uitbesteedt aan een externe provider, een cloudprovider die de beveiligingsdiensten uitbesteedt aan een provider van beheerde beveiligingsdiensten, gebruik van een externe provider voor identiteitsbeheer van besturingssystemen, enzovoort). Het omvat ook derden met fysieke of externe toegang tot de infrastructuur van de cloudprovider. Er wordt van uitgegaan dat deze volledige vragenlijst recursief kan worden toegepast op cloudserverproviders van een derde (of zoveelste) partij.

6.02. (a)

Definieer de diensten die in je toeleveringsketen voor dienstverlening worden uitbesteed of in onderaanneming worden gegeven en die essentieel zijn voor de beveiliging (inclusief beschikbaarheid) van je activiteiten.

Atlassian werkt samen met externe onderaannemers voor de website, ontwikkeling van de applicatie, hosting, onderhoud, back-up, opslag, virtuele infrastructuur, verwerking van betalingen, analyses en andere diensten. Een lijst van subverwerkers die momenteel door Atlassian worden ingeschakeld en door de klant zijn goedgekeurd, is te vinden op https://www.atlassian.com/legal/sub-processors.

6.02. (b)

Beschrijf de procedures die worden gebruikt om ervoor te zorgen dat derden toegang hebben tot je infrastructuur (fysiek en/of logisch).

• Controleer je je uitbestedingen en onderaannemers en hoe vaak?

Onze juridische teams en inkoopteams beoordelen contracten, SLA's en het interne beleid van leveranciers om de risico's in verband met beveiliging, beschikbaarheid en vertrouwelijkheid te beheersen. We voeren indien nodig ook functionele risicobeoordelingen uit op basis van het risicoprofiel. Risicobeoordelingen worden herzien als onderdeel van de hernieuwing van het beleid en op elk moment dat de relatie met de leverancier aanzienlijk verandert. Ons beleid voor het beheer van & externe gegevens van leveranciers omvat dit proces, waarvan een uittreksel hier beschikbaar is: https://www.atlassian.com/trust/security/ismp-policies

6.02. (c)

Zijn de SLA-bepalingen die worden gegarandeerd door uitbestedingen lager dan de SLA's die je je klanten aanbiedt? Zo nee, heb je dan redundantie van leveranciers?

Afhankelijk van de licentieovereenkomst moeten de cloudvoorwaarden van onze klanten worden bekeken bij de verlenging van het maandelijkse of jaarlijkse abonnement. Onze juridische teams en inkoopteams beoordelen contracten, SLA's en het interne beleid van leveranciers om de risico's in verband met beveiliging, beschikbaarheid en vertrouwelijkheid te beheersen. Het Enterprise Risk Management (ERM)-programma van Atlassian voert jaarlijks een risicobeoordeling uit waarin de waarschijnlijkheid en impact voor alle risicocategorieën zijn opgenomen en die is afgestemd op het COSO-risicomodel. We voeren indien nodig ook functionele risicobeoordelingen uit op basis van het risicoprofiel. Risicobeoordelingen worden herzien als onderdeel van de hernieuwing van het beleid en op elk moment dat de relatie met de leverancier aanzienlijk verandert.

6.02. (d)

Welke maatregelen worden genomen om ervoor te zorgen dat het serviceniveau van derden wordt gehaald en bijgehouden?

Onze juridische teams en inkoopteams beoordelen contracten, SLA's en het interne beleid van leveranciers om de risico's in verband met beveiliging, beschikbaarheid en vertrouwelijkheid te beheersen. We voeren indien nodig ook functionele risicobeoordelingen uit op basis van het risicoprofiel. Risicobeoordelingen worden herzien als onderdeel van de hernieuwing van het beleid en op elk moment dat de relatie met de leverancier aanzienlijk verandert. Ons beleid voor het beheer van & externe gegevens van leveranciers omvat dit proces, waarvan een uittreksel hier beschikbaar is: https://www.atlassian.com/trust/security/ismp-policies

6.02. (e)

Kan de cloudprovider bevestigen dat het beveiligingsbeleid en de beveiligingscontroles (contractueel) worden toegepast op hun externe providers?

Alle systemen en projecten worden onderworpen aan een impactbeoordeling met betrekking tot PII. Onze overeenkomsten voor derden van Atlassian bevatten beveiligings- en privacybepalingen, voor zover van toepassing. Nieuwe leveranciers bij Atlassian moeten in onze contracten instemmen met ons privacy- en veiligheidsbeleid.

Onze juridische teams en inkoopteams beoordelen contracten, SLA's en het interne beleid van leveranciers om de risico's in verband met beveiliging, beschikbaarheid en vertrouwelijkheid te beheersen. Het Enterprise Risk Management (ERM)-programma van Atlassian voert jaarlijks een risicobeoordeling uit waarin de waarschijnlijkheid en impact voor alle risicocategorieën zijn opgenomen en die is afgestemd op het COSO-risicomodel. We voeren indien nodig ook functionele risicobeoordelingen uit op basis van het risicoprofiel. Risicobeoordelingen worden herzien als onderdeel van de hernieuwing van het beleid en op elk moment dat de relatie met de leverancier aanzienlijk verandert.

6.03.

Er wordt verwacht dat elke commerciële overeenkomst met externe providers de serviceniveaus voor alle netwerkdiensten zal omvatten. Naast de vastgelegde overeenkomst moet de eindklant er echter nog steeds voor zorgen dat de provider passende controles toepast om ongeoorloofde openbaarmaking te beperken.

6.03. (a)

Beschrijf je procedure en beleid voor wijzigingsbeheer. Dit moet ook het proces omvatten dat wordt gebruikt om risico's als gevolg van veranderingen opnieuw te beoordelen en om te verduidelijken of de resultaten beschikbaar zijn voor eindgebruikers.

Atlassian heeft een Enterprise Risk Management (ERM)-programma dat is afgestemd op het COSO-risicomodel en ISO 31000. Het ERM-programma implementeert een kader en methodologie voor risicobeheer in Atlassian en voert jaarlijkse risicobeoordelingen, periodieke specifieke risicobeoordelingen van een productomgeving en functionele risicobeoordelingen uit, indien nodig, op basis van het risicoprofiel.

Het risicobeheerkader van Atlassian biedt met name normen, processen, rollen en verantwoordelijkheden, aanvaardbare risicotoleranties en richtlijnen voor de voltooiing van risicobeoordelingsactiviteiten. Onze risicobeheerprocessen en -praktijken zijn bepalend voor de voltooiing van onze risicobeoordelingen, die herhaalbaar zijn en resultaten opleveren die geldig, consistent en vergelijkbaar zijn. De risicobeoordelingen die Atlassian uitvoert, omvatten waarschijnlijkheid en impact van alle risicocategorieën, en de behandeling van alle risico's in vergelijking met onze intern ingestelde risicobereidheid. In alle fasen van het ERM-programma communiceert het Risk & Compliance-team met de relevante belanghebbenden en raadpleegt het relevante kleine en middelgrote ondernemingen.

Personeel dat een rol speelt in de risicobeheerprocessen van Atlassian is voldoende op de hoogte van en getraind in hun verantwoordelijkheden en de uitvoering van hun taken. Alle risico's worden gevolgd en beheerd met onze eigen Jira-tool, met eigenaarschap op managementniveau met bijbehorende behandelplannen en projecten. Zie https://www.atlassian.com/trust/security/security-management-program of https://www.atlassian.com/trust/compliance/risk-management-program voor meer informatie.

Ons Atlassian-verandermanagementproces is iets anders dan traditionele veranderprocessen. We vertrouwen op een Peer Review- en Green Build-controle (PRGB) voor alle veranderingen, of het nu gaat om veranderingen in de code, de applicatie of de infrastructuur. Peer Review is geconfigureerd in onze CD-tool, waarbij kritieke branches moeten worden aangewezen om meerdere beoordelaars te hebben voor elke Pull request. Gewoonlijk zijn dit twee ontwikkelaars en de teamleider. Het Green Build-gedeelte van de controle betekent dat de integratie tijdens de CI-fase alle integratie-, functionele, beveiligings- en andere tests moet doorstaan die zijn ontwikkeld. Als deze tests mislukken (een Red Build), wordt de code niet samengevoegd en moet deze opnieuw worden beoordeeld om de fouten aan te pakken. Zodra een Green Build succesvol is, wordt het binaire bestand cryptografisch ondertekend en gebruikt onze productieomgeving alleen binaire bestanden die zijn ondertekend met onze code. Ons testproces omvat zowel geautomatiseerde als handmatige beoordelingscomponenten. We bloggen graag over wat we goed doen. Onze benadering van het gebruik van 'quality assistance' (in plaats van gebruikelijke 'quality assurance') is iets waar we enthousiast over zijn: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance

6.03. (b)

Definieer het beleid voor toegang op afstand.

De vereisten voor toegang op afstand zijn gedefinieerd in het toegangsbeheerbeleid en de bijbehorende normen. Klantgegevens kunnen worden gerepliceerd naar de werkstations van werknemers voor support of migratiedoeleinden en met een actief klantenondersteuningsticket. Er gelden strikte firewallregels, waardoor de toegang tot de productieomgeving tot ons VPN-netwerk en geautoriseerde systemen wordt beperkt. Voor onze VPN-toegang is meervoudige verificatie vereist.

Alle apparaten (van Atlassian of BYOD) die door werknemers van Atlassian worden gebruikt en die toegang hebben tot ALLE Atlassian-tools, worden geregistreerd voor apparaatbeheer met behulp van beveiligingsprofielen van MDM-software en het controleren van de beveiliging. Atlassian gebruikt een Zero Trust-beveiligingsmodel voor alle Atlassian-apparaten. Lees hier meer: https://www.atlassian.com/trust/compliance/resources/eba/eba-guidance

6.03. (c)

Handhaaft de provider gedocumenteerde operationele procedures voor informatiesystemen?

De basisprincipes van Atlassian op het gebied van operationele beveiliging omvatten de ontwikkeling van standaard operationele proceduredocumenten. We hebben ook uittreksels gepubliceerd van elk van onze belangrijke beleidsmaatregelen met de tl:dr, die te vinden zijn op: https://www.atlassian.com/trust/security/ismp-policies

6.03. (d)

Is er een gefaseerde omgeving om risico's te verminderen, bijvoorbeeld ontwikkelings-, test- en operationele omgevingen, en zijn die gescheiden?

Atlassian heeft een informatiebeveiligingsbeleid dat het gebruik van productiegegevens in niet-productieomgevingen verbiedt, en elke poging tot gegevensmigratie tussen de omgevingen zou worden geïdentificeerd aan de hand van het verandermanagementproces.z De code gaat over van een gecentraliseerd bouwsysteem waarbij eerst eenheden worden getest. Vervolgens naar validatie van de functie-branch met aanvullende testautomatisering en poortbeoordelingen door PM, Dev, QA. Vervolgens naar UAT, beveiliging en prestatievalidatie. Ontwikkelaars kunnen code niet rechtstreeks in productie promoten. Meer informatie is beschikbaar op https://www.atlassian.com/trust/security/security-practices#managing-changes-in-our-environment

We handhaven logische en fysieke scheiding van productie- en ontwikkelingsomgevingen en methoden voor het isoleren van deze omgevingen.

Onze staging-omgeving is logisch gescheiden (maar niet fysiek gescheiden) en wordt beheerd onder controle- en toegangsprocessen van productiekwaliteit. Ga voor meer informatie over onze praktijken op het gebied van codebeveiliging naar: https://www.atlassian.com/trust/security/security-in-development.

6.03. (e)

Definieer de host- en netwerkcontroles die worden gebruikt om de systemen die de applicaties en informatie voor de eindklant hosten, te beschermen. Deze moeten gegevens bevatten over de certificering volgens externe normen (bijvoorbeeld ISO 27001/2).

Atlassian Network Engineering maakt gebruik van IPS-technologieën die zijn ingebouwd in onze firewalls in de cloud en op kantoor. Ook heeft Atlassian IDS-technologieën geïmplementeerd in onze kantooromgevingen. De bescherming tegen netwerkbedreigingen wordt uitgevoerd door AWS, waaronder DDoS-bescherming en enkele firewallfuncties voor webtoepassingen. Alle gegevens voor onze diensten worden tijdens het transport versleuteld met behulp van TLS om ze te beschermen tegen ongeoorloofde openbaarmaking of wijziging, of dat nu via HTTPS of SMTPS gebeurt.

Atlassian heeft de SOC2-, ISO27001- en ISO27018-certificeringen behaald voor onze cloudservices. We voeren minstens jaarlijks zowel interne audits/audits over gereedheid als externe audits uit.

Ga voor meer informatie naar: https://www.atlassian.com/trust/compliance. Klanten moeten op deze site regelmatig updates van onze conformiteitscertificaten en -rapporten downloaden en lezen.

6.03. (f)

Specificeer de controles die worden gebruikt ter bescherming tegen schadelijke code.

Atlassian heeft Crowdstrike Falcon geïmplementeerd (https://www.crowdstrike.com/falcon-platform/) voor ons assortiment Windows en Mac. We gebruiken geen antimalware op onze Linux-machines. Antimalware is opgenomen in ons beleid voor kwetsbaarheidsbeheer.

We hanteren een beleid voor bedreigings- en kwetsbaarheidsbeheer. Ons Policy Management Program (PMP) is gedefinieerd en omvat eigendom, beschikbaarheid en beoordelingscyclus, en schetst onze algemene doelstellingen. Onze beleidsregels worden minstens jaarlijks herzien en goedgekeurd door het senior management. Meer informatie over ons PMP is te vinden op: https://www.atlassian.com/trust/security/security-management-program

We hebben ook uittreksels gepubliceerd van elk van onze belangrijke beleidsmaatregelen met de tl:dr, die te vinden zijn op: https://www.atlassian.com/trust/security/ismp-policies

6.03. (g)

Worden veilige configuraties geïmplementeerd om alleen de uitvoering van geautoriseerde mobiele code en geautoriseerde functionaliteit mogelijk te maken (bijvoorbeeld om alleen specifieke opdrachten uit te voeren)?

Alle servers zijn geconfigureerd via ons gecentraliseerde puppetconfiguratiesysteem voor onze standaard besturingsomgeving, inclusief het verwijderen van bepaalde pakketten uit de standaardafbeelding en essentiële pakketupdates. Voor alle serverrollen geldt standaard 'alles afwijzen' voor binnenkomende netwerkaanvragen, waarbij bepaalde poorten alleen toegankelijk zijn voor de andere serverrollen die toegang nodig hebben tot die poort om te kunnen functioneren.

Ons bedrijfsnetwerk is gescheiden van ons productienetwerk, en onze machine-image zijn gehard zodat alleen de noodzakelijke poorten en protocollen mogelijk zijn. Alle productiesystemen worden momenteel gehost in Amerikaanse regio's van onze cloudprovider. Alle gegevens die buiten geharde virtuele privécloudnetwerken (VPC) worden doorgevoerd, worden versleuteld via kanalen volgens de industriestandaard.

Daarbij is er op alle productieservers een IDS-systeem geïnstalleerd, dat zorgt voor realtime monitoring en waarschuwing bij eventuele veranderingen in de bestanden of configuratie van het productiesysteem en abnormale beveiligingsgebeurtenissen.

Verder hebben we een gecentraliseerde oplossing voor systeembeheer geïmplementeerd (https://www.jamf.com/lp/apple-mobile-device-management-mdm-jamf/) voor ons assortiment Mac-laptops. We gebruiken volledige schijfversleuteling op onze laptops. We hebben ook een oplossing voor mobiel apparaatbeheer geïmplementeerd voor onze smartphones (https://www.vmware.com/products/workspace-one.html). Alle apparaten moeten geregistreerd zijn om toegang te krijgen tot interne systemen en applicaties. Als een mobiel apparaat niet is geregistreerd, hebben ze geen toegang tot interne bronnen en zitten ze zich op een gastnetwerk dat alleen toegang heeft tot het internet. De toegang wordt beheerd door middel van toegangscontroles op basis van functies om ervoor te zorgen dat alleen gebruikers die toegang nodig hebben tot de gegevens van klant/tenant, deze hebben.

6.03. (h)

Gedetailleerde beleidsregels en procedures voor back-up. Dit moet procedures omvatten voor het beheer van verwijderbare media en methoden voor de veilige vernietiging van media die niet langer nodig zijn. (Afhankelijk van de behoeften van het bedrijf kan het zijn dat de klant een onafhankelijke back-upstrategie wilt invoeren. Dit is met name relevant wanneer tijdgevoelige toegang tot back-up vereist is.)

We werken bij Atlassian met een uitgebreid back-upprogramma. Dit omvat onze interne systemen, waar onze back-upmaatregelen zijn ontworpen in overeenstemming met de vereisten voor systeemherstel. We hebben bovendien uitgebreide back-upmaatregelen genomen voor onze Cloud-producten, in het bijzonder voor jou en je applicatiegegevens. We gebruiken de snapshotfunctie van Amazon RDS (Relational Database Service) om automatische dagelijkse back-ups te maken van elke RDS-installatie. Amazon RDS-snapshots worden 30 dagen lang bewaard met ondersteuning voor point-in-time-herstel en worden versleuteld met AES-256-versleuteling. Back-upgegevens worden niet extern opgeslagen maar worden gekopieerd naar meerdere data centers binnen een specifieke AWS-regio. Bovendien testen we onze back-ups ieder kwartaal. Voor Bitbucket worden gegevens gerepliceerd naar een andere AWS-regio en er worden dagelijks onafhankelijke back-ups gemaakt binnen elke regio.

We gebruiken deze back-ups niet om door klanten geïnitieerde vernietigende veranderingen, zoals velden die zijn overschreven met scripts of verwijderde issues, projecten of sites, ongedaan te maken. Om gegevensverlies te voorkomen, raden we aan regelmatig back-ups te maken. Meer informatie over het maken van back-ups vind je in de supportdocumentatie voor je product. Klanten moeten ook hun eigen periodieke back-ups maken om door de klant geïnitieerde veranderingen terug te kunnen draaien. Zie https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/#Can-Atlassian%E2%80%99s-RDS-backups-be-used-to-roll-back-changes voor meer informatie.

Atlassian hanteert een standaard voor gegevensbehoud en -vernietiging, die aangeeft hoelang we verschillende soorten gegevens moeten bewaren. Gegevens worden geclassificeerd in overeenstemming met ons Atlassian-beleid inzake gegevensbeveiliging en levenscyclus van informatie. Op basis daarvan worden controles geïmplementeerd. Voor klantgegevens: na beëindiging van een Atlassian-contract worden de gegevens van een klantenteam verwijderd uit de live productiedatabase en worden alle bestandsbijlagen die rechtstreeks naar Atlassian zijn geüpload binnen 14 dagen verwijderd. De gegevens van het team blijven in versleutelde back-ups staan totdat de bewaartermijn van 90 dagen voor back-ups vervalt. Daarna worden de gegevens vernietigd in overeenstemming met ons Atlassian-beleid voor gegevensbehoud. In het geval dat een databaseherstel nodig is binnen 90 dagen na het verwijderen van de gevraagde gegevens, verwijdert het operationele team de gegevens opnieuw zo snel als redelijkerwijs mogelijk nadat het live productiesysteem volledig is hersteld. Ga voor meer informatie naar https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

Auditlogs worden gebruikt in geval van een incident waarvoor onderzoek nodig is en voor het oplossen van problemen. Voor deze doeleinden heeft de eindklant de zekerheid nodig dat dergelijke informatie beschikbaar is.

6.03. (i)

Kan de provider aangeven welke informatie is vastgelegd in de auditlogs?

• Hoelang worden deze gegevens bewaard?
• Is het mogelijk om gegevens in auditlogs te segmenteren, zodat ze beschikbaar kunnen worden gesteld aan de eindklant en/of de politie zonder dat andere klanten hierdoor in gevaar worden gebracht en de gegevens toch aanvaardbaar zijn voor de rechtbank?
• Welke controles worden gebruikt om logs te beschermen tegen ongeautoriseerde toegang of manipulatie?
• Welke methode wordt gebruikt om de integriteit van auditlogs te controleren en te beschermen?

Sleutelsysteemlogs worden vanaf elk systeem doorgestuurd naar een gecentraliseerd logplatform, waar logs alleen gelezen kunnen worden. Het Beveiligingsteam van Atlassian maakt waarschuwingen aan op ons platform voor beveiligingsanalyses (Splunk) en controleert op tekenen van schade. Onze SRE-teams gebruiken het platform om te controleren op problemen met beschikbaarheid of prestaties. Logs worden 30 dagen bewaard in de hot back-up en 365 dagen in de cold back-up.

Atlassian beperkt de mogelijkheid om auditlogs te bekijken en te lezen tot bevoegd personeel op ons gecentraliseerde logplatform.

Atlassian hanteert een standaard voor gegevensbehoud en -vernietiging, die aangeeft hoe lang we verschillende soorten gegevens moeten bewaren. Gegevens worden geclassificeerd in overeenstemming met ons Atlassian-beleid inzake gegevensbeveiliging en levenscyclus van informatie. Op basis daarvan worden controles geïmplementeerd. Voor klantgegevens: na beëindiging van een Atlassian-contract worden de gegevens van een klantenteam verwijderd uit de live productiedatabase en worden alle bestandsbijlagen die rechtstreeks naar Atlassian zijn geüpload binnen 14 dagen verwijderd. De gegevens van het team blijven in versleutelde back-ups staan totdat de bewaartermijn van 90 dagen voor back-ups vervalt. Daarna worden de gegevens vernietigd in overeenstemming met ons Atlassian-beleid voor gegevensbehoud. In het geval dat een databaseherstel nodig is binnen 90 dagen na het verwijderen van de gevraagde gegevens, verwijdert het operationele team opnieuw de gegevens zo snel als redelijkerwijs mogelijk nadat het live productiesysteem volledig is hersteld. Ga voor meer informatie naar https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

6.03. (j)

Hoe worden auditlogs beoordeeld? Welke geregistreerde gebeurtenissen hebben tot gevolg dat er actie wordt ondernomen?

Sleutelsysteemlogs worden vanaf elk systeem doorgestuurd naar een gecentraliseerd logplatform, waar logs alleen gelezen kunnen worden. Het Beveiligingsteam van Atlassian maakt waarschuwingen aan op ons platform voor beveiligingsanalyses (Splunk) en controleert op tekenen van schade. Onze SRE-teams gebruiken het platform om te controleren op problemen met beschikbaarheid of prestaties. Logs worden 30 dagen bewaard in hot back-up en 365 dagen in de cold back-up.

Atlassian beperkt de mogelijkheid om auditlogs te bekijken en te lezen tot bevoegd personeel op ons gecentraliseerde logplatform.

6.03. (k)

Welke tijdbron wordt gebruikt om systemen te synchroniseren en nauwkeurige tijdstempels voor auditlogs te geven?

Atlassian Cloud maakt gebruik van AWS Time Sync voor alle geïmplementeerde installaties.

6.03.01. (a)

Definieer de controles die worden gebruikt om de integriteit van het gebruikte besturingssysteem en de applicatiesoftware te beschermen. Voeg alle standaarden toe die worden gevolgd, zoals OWASP, SANS Checklist, SAFECode.

Ons team van beveiligingsingenieurs evalueert voortdurend alle broncode in onze producten als onderdeel van onze ontwikkelingscyclus. Er worden zowel geautomatiseerde als handmatige technieken gebruikt. We maken ook gebruik van een verplicht proces voor dubbele collegiale toetsing, waarbij meerdere senior- en hoofdontwikkelaars alle commits beoordelen om de master te behalen. Dankzij Agile-workflows kunnen we eventuele kwetsbaarheden snel identificeren en oplossen, met name voor onze cloudservices.

Het beveiligde codebeoordelingsproces van Atlassian omvat automatisch scannen (d.w.z. analyse van de softwaresamenstelling) voor bekende kwetsbaarheden, waaronder kwetsbaarheden die worden misbruikt bij aanvallen in de echte wereld. Bovendien scant ons programma voor kwetsbaarheidsbeheer hosts en containerafbeeldingen op bekende kwetsbaarheden met behulp van Snyk. Zie https://www.atlassian.com/trust/security/data-management voor meer informatie.

We werken samen met BugCrowd om een Bug Bounty-programma in stand te houden en om doorlopend kwetsbaarheidsbeoordelingen uit te voeren van onze openbaar beschikbare Applicaties en Diensten. Het programma is beschikbaar op: https://bugcrowd.com/atlassian. We delen de resultaten van lopende pentests van ons Bug Bounty-programma op: https://www.atlassian.com/trust/security/security-testing.

6.03.01. (b)

Hoe bevestig je dat nieuwe releases geschikt zijn voor het beoogde doel of geen risico's met zich meebrengen (backdoors, trojans, enz.)? Worden deze vóór gebruik beoordeeld?

Ons Atlassian-verandermanagementproces is iets anders dan traditionele veranderprocessen. We vertrouwen op een Peer Review- en Green Build-controle (PRGB) voor alle veranderingen, of het nu gaat om veranderingen in de code, applicatie of infrastructuur. Peer Review is geconfigureerd in onze CD-tool, waarbij kritieke branches moeten worden aangewezen om meerdere beoordelaars te hebben voor elk Pull request. Gewoonlijk zijn dit twee ontwikkelaars en de teamleider. Het Green Build-gedeelte van de controle betekent dat de integratie tijdens de CI-fase alle integratie-, functionele, beveiligings- en andere tests moet doorstaan die zijn ontwikkeld. Als deze tests mislukken (een zogenaamde Red Build), wordt de code niet samengevoegd en moet deze opnieuw worden beoordeeld om de fouten aan te pakken. Zodra een Green Build gelukt is, wordt het binaire bestand cryptografisch ondertekend. In onze productieomgeving worden alleen binaire bestanden gebruikt die zijn ondertekend met onze sleutel. Ons testproces omvat zowel geautomatiseerde als handmatige beoordelingscomponenten. We bloggen graag over wat we goed doen. Onze benadering van het gebruik van 'quality assistance' (in plaats van gebruikelijke 'quality assurance') is iets waar we enthousiast over zijn. Zie: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance.

Na de implementatie maken we regelmatig gebruik van geautomatiseerde kwetsbaarheidscans en een toonaangevend bug bounty-programma (https://bugcrowd.com/atlassian) om continue zekerheid van onze applicaties te bieden. Veranderingen in de systeemconfiguratie worden beheerd door een geautomatiseerd proces dat een beoordeling omvat.

Het beoordelingsproces voor beveiligde codes van Atlassian omvat automatisch scannen (d.w.z. analyse van de softwaresamenstelling) voor bekende kwetsbaarheden, waaronder kwetsbaarheden waar misbruik van wordt gemaakt bij aanvallen in de echte wereld. Bovendien scant ons programma voor kwetsbaarheidsbeheer hosts en containerafbeeldingen op bekende kwetsbaarheden met behulp van Snyk. Zie https://www.atlassian.com/trust/security/data-management voor meer informatie.

6.03.01. (c)

Welke praktijken worden gevolgd om de applicaties veilig te houden?

Onze applicaties vereisen een Peer Review en Green Build (PRGB), waarna de artefacten van de applicatie cryptografisch worden ondertekend, automatisch worden geïmplementeerd door onze CI/CD-pipeline. Alleen door Atlassian ondertekende applicaties kunnen worden uitgevoerd in onze productieomgeving.

Atlassian hanteert veilige ontwikkelingsmethoden in alle fasen van de ontwikkelingscyclus. Bekijk https://www.atlassian.com/trust/security/security-in-development voor meer informatie.

Tijdens de ontwerpfase worden praktijken als dreigingsmodellering, ontwerpbeoordeling en onze regelmatig bijgewerkte bibliotheek met beveiligingsnormen ingezet. Deze zorgen ervoor dat er rekening wordt gehouden met de juiste beveiligingsvereisten. Tijdens de ontwikkeling vertrouwen we op een verplicht peer review-proces als eerste stap van de beveiligingsbeoordeling. Dit proces wordt ondersteund door geautomatiseerde statische analysecontroles (SAST) en handmatige beveiligingstests (zowel door interne teams als externe experts, zoals bepaald door ons risicobeoordelingsproces). De ontwikkeling wordt ook ondersteund door trainingsprogramma's voor applicatiebeveiliging en een kennisdatabase voor beveiliging die wordt onderhouden door het beveiligingsteam. Formele operationele gereedheid en veranderingscontroleprocessen zorgen er vervolgens voor dat alleen goedgekeurde veranderingen in de productie worden geïmplementeerd. Na de implementatie maken we regelmatig gebruik van geautomatiseerde kwetsbaarheidscans en een toonaangevend bug bounty-programma (https://bugcrowd.com/atlassian) om continue zekerheid van onze applicaties te bieden. Veranderingen in de systeemconfiguratie worden beheerd door een geautomatiseerd proces, dat een beoordeling omvat van alle veranderingen voordat ze in productie worden genomen. Atlassian Service Operations kan patches implementeren zodra er een substantieel risico is vastgesteld. We hebben interne criteria om te bepalen hoe snel patches moeten worden geïmplementeerd. We kunnen deze binnen 12 uur toepassen op alle machines. Er is ook een IDS-systeem dat het monitoren van de systeemconfiguratiebestanden omvat.

6.03.01. (d)

Is de penetratie van een softwarerelease getest om er zeker van te zijn dat deze geen kwetsbaarheden bevat? Als er kwetsbaarheden worden ontdekt, wat is dan de procedure om deze te verhelpen?

Atlassian hanteert veilige ontwikkelingsmethoden in alle fasen van de ontwikkelingscyclus. Bekijk https://www.atlassian.com/trust/security/security-in-development voor meer informatie.

Tijdens de ontwikkeling vertrouwen we op een verplicht peer review-proces als eerste lijn van beveiligingsbeoordeling. Dit proces wordt ondersteund door geautomatiseerde statische analysecontroles (SAST) en handmatige beveiligingstests (zowel door interne teams als externe experts, zoals bepaald door ons risicobeoordelingsproces). De ontwikkeling wordt ook ondersteund door trainingsprogramma's voor applicatiebeveiliging en een kennisdatabase voor beveiliging die wordt onderhouden door het beveiligingsteam.

Formele operationele gereedheid en veranderingscontroleprocessen zorgen er vervolgens voor dat alleen goedgekeurde wijzigingen in productie worden geïmplementeerd. Na de implementatie maken we regelmatig gebruik van geautomatiseerde kwetsbaarheidscans en een toonaangevend bug bounty-programma (https://bugcrowd.com/atlassian) om continue zekerheid van onze applicaties te bieden.

6.03.02. (a)

Verstrek je informatie over de gevolgde procedure voor patchbeheer?

We hanteren een beleid voor bedreigings- en kwetsbaarheidsbeheer. Ons Policy Management Program (PMP) is gedefinieerd en omvat eigendom, beschikbaarheid en een beoordelingscyclus, en schetst onze algemene doelstellingen. Onze beleidsregels worden minstens jaarlijks herzien en goedgekeurd door het seniorbeheer. Meer informatie over ons PMP is te vinden op: https://www.atlassian.com/trust/security/security-management-program

We hebben ook uittreksels gepubliceerd van elk van onze belangrijke beleidsmaatregelen met de tl:dr, die te vinden zijn op: https://www.atlassian.com/trust/security/ismp-policies

Bij Atlassian wordt gebruik gemaakt van een combinatie van eindpuntbeheer om updates en patches te implementeren voor besturingssystemen en belangrijke applicaties overal in onze reeks eindpunten. We hebben ook meerdere oplossingen voor eindpuntbescherming geïmplementeerd voor bescherming tegen bedreigingen zoals malware. Zie https://www.atlassian.com/trust/security/security-practices#keeping-track-of-information-assets voor meer informatie.

6.03.02. (b)

Kun je ervoor zorgen dat het patchbeheerproces alle lagen van de cloudleveringstechnologieën omvat, zoals het netwerk (infrastructuurcomponenten, routers en switches, enz.), besturingssystemen voor servers, virtualisatiesoftware, applicaties en beveiligingssubsystemen (firewalls, antivirus-gateways, inbraakdetectiesystemen, enz.)?

Veranderingen in de systeemconfiguratie worden beheerd door een geautomatiseerd proces, dat een beoordeling omvat van alle veranderingen voordat ze in productie worden geïmplementeerd. Atlassian Service Operations kan patches implementeren zodra er een substantieel risico is vastgesteld. We hebben interne criteria om te bepalen hoe snel patches moeten worden geïmplementeerd. We kunnen deze binnen 12 uur toepassen op alle machines. Er is ook een IDS-systeem dat het monitoren van de systeemconfiguratiebestanden omvat.

Atlassian Cloud-producten kunnen zo snel als nodig worden geüpdatet naar de nieuwste AMI. Onze SaaS-applicaties worden meerdere keren per week geüpdatet. We hebben snelle en gecontroleerde implementatiemechanismen voor updates van onze code en systeemconfiguraties. Bij Atlassian wordt actief gebruikgemaakt van een veranderingscontrole voor ongeplande en noodveranderingen.

6.03.03. (a)

Definieer de controles die worden gebruikt om DDoS-aanvallen (Distributed Denial-of-Service) te beperken.

• Diepgaande verdediging (analyse van diepe pakketten, verkeersbeperking, black-holding van pakketten, enz).
• Heb je bescherming tegen 'interne' aanvallen (afkomstig van netwerken van cloudproviders) en externe aanvallen (afkomstig van het internet of klantnetwerken)?
<

De vereisten voor netwerkbeveiliging zijn gedefinieerd in het Communicatiebeveiligingsbeleid. Dit wordt elk jaar herzien in overeenstemming met ons Policy Management Program (PMP). Ga voor meer informatie over onze PMP naar: https://www.atlassian.com/trust/security/security-management-program

Ons Atlassian Cloud Platform heeft heel weinig oppervlakte dat via de firewalls wordt blootgesteld. We herzien de firewall-regels periodiek. We hebben IDS geïmplementeerd op onze kantoorlocaties en in onze cloudhostingomgeving. Voor het Atlassian Cloud Platform kan het doorsturen van logs geïntegreerd worden met een platform voor beveiligingsanalyse. Op containerniveau van het Cloud Platform wordt de bestandsintegriteit gehandhaafd omdat de installaties niet kunnen worden aangepast. Bij Atlassian Network Engineering wordt gebruikgemaakt van IPS-technologieën die zijn ingebouwd in onze firewalls. Ook hebben we IDS-technologieën geïmplementeerd in onze kantoor- en cloudomgevingen. DDoS-mogelijkheden worden geleverd door onze internetprovider.

De prestaties van onze firewalls worden ook regelmatig beoordeeld aan de hand van onze programma's voor kwetsbaarheidsbeoordelingen (https://www.atlassian.com/trust/security/vulnerability-management) en programma's voor penetratietests (https://www.atlassian.com/trust/security/security-testing).

6.03.03. (b)

Welke isolatieniveaus worden er gebruikt?

• Voor virtuele machines, fysieke machines, netwerken, opslag (bijv. storage area networks (SAN)), managementnetwerken en managementsupportsystemen, enz.
<

Atlassian is een SaaS-applicatie voor meerdere tenants. Het hebben van meerdere tenants is een belangrijk kenmerk van Atlassian Cloud waardoor meerdere klanten één installatie van de Jira- of Confluence-applicatielaag kunnen delen, terwijl de applicatiegegevens van elke tenant van de klant worden geïsoleerd. Atlassian Cloud doet dit via de Tenant Context Service (TCS). Elke gebruikers-ID is gekoppeld aan precies één tenant, die vervolgens wordt gebruikt voor toegang tot de Atlassian Cloud-applicaties. Ga voor meer informatie naar: https://www.atlassian.com/trust/security/security-practices#tenant-isolation

We handhaven logische en fysieke scheiding van productie- en ontwikkelingsomgevingen en methoden voor het isoleren van deze omgevingen.

Onze staging-omgeving is logisch gescheiden (maar niet fysiek gescheiden) en wordt beheerd onder controle- en toegangsprocessen van productiekwaliteit.

6.03.03. (c)

Ondersteunt de architectuur de voortzetting van activiteiten vanuit de cloud wanneer het bedrijf is gescheiden van de serviceprovider en vice versa (is er bijvoorbeeld een kritieke afhankelijkheid van het LDAP-systeem van de klant)?

Er is een beleid en een plan voor bedrijfscontinuïteit en disaster recovery van kracht; deze worden jaarlijks herzien door de stuurgroep voor Bedrijfscontinuïteit/Disaster recovery. Ga voor meer informatie naar: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e en https://www.atlassian.com/trust/security/data-management.

Atlassian maakt gebruik van hoge beschikbaarheids- datacenter-faciliteiten van AWS in meerdere regio's over de hele wereld om te zorgen dat de activiteiten worden voortgezet. Zie https://www.atlassian.com/trust/security/data-management voor meer informatie.

6.03.03. (d)

Is de virtuele netwerkinfrastructuur die door cloudproviders wordt gebruikt (in de tagging 802.1q-architectuur van PVLAN's en VLAN) beveiligd volgens de specifieke normen van leveranciers en/of best practices (worden bijvoorbeeld aanvallen met MAC-spoofing, ARP-spoofing, enz. voorkomen via een specifieke beveiligingsconfiguratie)?

De vereisten voor netwerkbeveiliging zijn gedefinieerd in het Communicatiebeveiligingsbeleid. Dit wordt elk jaar herzien in overeenstemming met ons Policy Management Program (PMP). Ga voor meer informatie over onze PMP naar: https://www.atlassian.com/trust/security/security-management-program

Ons Atlassian Cloud Platform heeft heel weinig oppervlakte dat door de firewalls wordt blootgesteld. We herzien de firewallregels periodiek. We hebben IDS geïmplementeerd op onze kantoorlocaties en in onze cloudhostingomgeving. Voor het Atlassian Cloud Platform kan het doorsturen van logs geïntegreerd worden met een platform voor beveiligingsanalyse. Op containerniveau van het Cloud Platform wordt de bestandsintegriteit gehandhaafd omdat de installaties niet kunnen worden gewijzigd. Atlassian Network Engineering maakt gebruik van IPS-technologieën die zijn ingebouwd in onze firewalls. Ook hebben we IDS-technologieën geïmplementeerd in onze kantoor- en cloudomgevingen. DDoS-mogelijkheden worden geleverd door onze internetprovider.

De prestaties van onze firewalls worden ook regelmatig beoordeeld aan de hand van onze programma's voor kwetsbaarheidsbeoordelingen (https://www.atlassian.com/trust/security/vulnerability-management) en penetratietests (https://www.atlassian.com/trust/security/security-testing) .

Daarbij bewaken we bij Atlassian de configuratie van onze AWS-omgevingen op basis van gevestigde uitgangswaarden voor configuraties.

6.03.04. (a)

Zorgt de provider ervoor dat virtuele images standaard gehard zijn?

Alle servers zijn geconfigureerd via ons gecentraliseerde puppetconfiguratiesysteem voor onze standaard besturingsomgeving, inclusief het verwijderen van bepaalde pakketten uit de standaardimage en essentiële pakketupdates. Voor alle serverrollen geldt standaard 'alles afwijzen' voor binnenkomende netwerkaanvragen, waarbij bepaalde poorten alleen toegankelijk zijn voor de andere serverrollen die toegang nodig hebben tot die poort om te kunnen functioneren.

Ons bedrijfsnetwerk is gescheiden van ons productienetwerk, en onze machine-image zijn gehard zodat alleen de noodzakelijke poorten en protocollen mogelijk zijn. Alle productiesystemen worden momenteel gehost in Amerikaanse regio's van onze cloudprovider. Alle gegevens die buiten geharde virtuele privécloudnetwerken (VPC) worden doorgevoerd, worden versleuteld via kanalen volgens de industriestandaard.

Daarbij is er op alle productieservers een IDS-systeem geïnstalleerd, dat zorgt voor realtime monitoring en waarschuwing bij eventuele veranderingen in de bestanden of configuratie van het productiesysteem en abnormale beveiligingsgebeurtenissen.

Op het Atlassian Cloud Platform hebben individuele containers geen image. Wanneer de container wordt gestart, wordt er een image gekozen uit een standaard repository. We blijven alle images auditeren en zorgen ervoor dat de images opnieuw worden toegepast door onze configuratietools wanneer dat nodig is. Als gevolg hiervan worden er geen wijzigingen aangebracht in de images van de virtuele machine.

De imageversies van het AWS Linux AMI-basisbesturingssysteem hebben een beperkt aantal poorten, protocollen en services. We vergelijken onze versies met de huidige AMI-versie om zeker te zijn van de juiste instellingen.

Onze Docker-images worden beheerd in een streng gecontroleerde veranderomgeving om ervoor te zorgen dat alle wijzigingen op de juiste manier worden beoordeeld en goedgekeurd.

6.03.04. (b)

Is de geharde virtuele image beschermd tegen ongeoorloofde toegang?

Alle servers zijn geconfigureerd via ons gecentraliseerde puppetconfiguratiesysteem voor onze standaard besturingsomgeving, inclusief het verwijderen van bepaalde pakketten uit de standaardimage en essentiële pakketupdates. Voor alle serverrollen geldt standaard 'alles afwijzen' voor binnenkomende netwerkaanvragen, waarbij bepaalde poorten alleen toegankelijk zijn voor de andere serverrollen die toegang nodig hebben tot die poort om te kunnen functioneren.

Ons bedrijfsnetwerk is gescheiden van ons productienetwerk, en onze machine-image zijn gehard zodat alleen de noodzakelijke poorten en protocollen mogelijk zijn. Alle productiesystemen worden momenteel gehost in Amerikaanse regio's van onze cloudprovider. Alle gegevens die buiten geharde virtuele privécloudnetwerken (VPC) worden doorgevoerd, worden versleuteld via kanalen volgens de industriestandaard.

Daarbij is er op alle productieservers een IDS-systeem geïnstalleerd, dat zorgt voor realtime monitoring en waarschuwing bij eventuele veranderingen in de bestanden of configuratie van het productiesysteem en abnormale beveiligingsgebeurtenissen.

Op het Atlassian Cloud Platform hebben individuele containers geen image. Wanneer de container wordt gestart, wordt er een image gekozen uit een standaard repository. We blijven alle images auditeren en zorgen ervoor dat de images opnieuw worden toegepast door onze configuratietools wanneer dat nodig is. Als gevolg hiervan worden er geen wijzigingen aangebracht in de images van de virtuele machine.

De imageversies van het AWS Linux AMI-basisbesturingssysteem hebben een beperkt aantal poorten, protocollen en services. We vergelijken onze versies met de huidige AMI-versie om zeker te zijn van de juiste instellingen.

Onze Docker-images worden beheerd in een streng gecontroleerde veranderomgeving om ervoor te zorgen dat alle wijzigingen op de juiste manier worden beoordeeld en goedgekeurd.

Ons wereldwijde supportteam handhaaft een account op alle gehoste systemen en applicaties voor onderhoud en support. Dit supportteam heeft uitsluitend toegang tot gehoste applicaties en gegevens om gezondheidscontroles en onderhoudswerkzaamheden aan systemen of applicaties uit te voeren, en op aanvraag van de klant via ons supportsysteem.

6.03.04. (c)

Kan de provider bevestigen dat de gevirtualiseerde image geen toegangsgegevens voor authenticatie bevat?

Alle servers zijn geconfigureerd via ons gecentraliseerde puppetconfiguratiesysteem voor onze standaard besturingsomgeving, inclusief het verwijderen van bepaalde pakketten uit de standaardimage en essentiële pakketupdates. Voor alle serverrollen geldt standaard 'alles afwijzen' voor binnenkomende netwerkaanvragen, waarbij bepaalde poorten alleen toegankelijk zijn voor de andere serverrollen die toegang nodig hebben tot die poort om te kunnen functioneren.

Ons bedrijfsnetwerk is gescheiden van ons productienetwerk, en onze machine-image zijn gehard zodat alleen de noodzakelijke poorten en protocollen mogelijk zijn. Alle productiesystemen worden momenteel gehost in Amerikaanse regio's van onze cloudprovider. Alle gegevens die buiten geharde virtuele privécloudnetwerken (VPC) worden doorgevoerd, worden versleuteld via kanalen volgens de industriestandaard.

Daarbij is er op alle productieservers een IDS-systeem geïnstalleerd, dat zorgt voor realtime monitoring en waarschuwing bij eventuele veranderingen in de bestanden of configuratie van het productiesysteem en abnormale beveiligingsgebeurtenissen.

Op het Atlassian Cloud Platform hebben individuele containers geen image. Wanneer de container wordt gestart, wordt er een image gekozen uit een standaard repository. We blijven alle images auditeren en zorgen ervoor dat de images opnieuw worden toegepast door onze configuratietools wanneer dat nodig is. Als gevolg hiervan worden er geen wijzigingen aangebracht in de images van de virtuele machine.

De imageversies van het AWS Linux AMI-basisbesturingssysteem hebben een beperkt aantal poorten, protocollen en services. We vergelijken onze versies met de huidige AMI-versie om zeker te zijn van de juiste instellingen.

Onze Docker-images worden beheerd in een streng gecontroleerde veranderomgeving om ervoor te zorgen dat alle wijzigingen op de juiste manier worden beoordeeld en goedgekeurd.

Ons wereldwijde supportteam handhaaft een account op alle gehoste systemen en applicaties voor onderhoud en support. Dit supportteam heeft uitsluitend toegang tot gehoste applicaties en gegevens om gezondheidscontroles en onderhoudswerkzaamheden aan systemen of applicaties uit te voeren, en op aanvraag van de klant via ons supportsysteem.

6.03.04. (d)

Wordt de hostfirewall uitgevoerd met alleen de minimale poorten die nodig zijn om de services binnen de virtuele installatie te ondersteunen?

Alle servers zijn geconfigureerd via ons gecentraliseerde puppetconfiguratiesysteem voor onze standaard besturingsomgeving, inclusief het verwijderen van bepaalde pakketten uit de standaardimage en essentiële pakketupdates. Voor alle serverrollen geldt standaard 'alles afwijzen' voor binnenkomende netwerkaanvragen, waarbij bepaalde poorten alleen toegankelijk zijn voor de andere serverrollen die toegang nodig hebben tot die poort om te kunnen functioneren.

Ons bedrijfsnetwerk is gescheiden van ons productienetwerk, en onze machine-image zijn gehard zodat alleen de noodzakelijke poorten en protocollen mogelijk zijn. Alle productiesystemen worden momenteel gehost in Amerikaanse regio's van onze cloudprovider. Alle gegevens die buiten geharde virtuele privécloudnetwerken (VPC) worden doorgevoerd, worden versleuteld via kanalen volgens de industriestandaard.

Ons Atlassian Cloud Platform heeft heel weinig oppervlakte dat door de firewalls wordt blootgesteld. We herzien de firewallregels periodiek. We hebben IDS geïmplementeerd op onze kantoorlocaties en in onze cloudhostingomgeving. Voor het Atlassian Cloud Platform kan het doorsturen van logs geïntegreerd worden met een platform voor beveiligingsanalyse. Op containerniveau van het Cloud Platform wordt de bestandsintegriteit gehandhaafd omdat de installaties niet kunnen worden gewijzigd. Atlassian Network Engineering maakt gebruik van IPS-technologieën die zijn ingebouwd in onze firewalls. Ook hebben we IDS-technologieën geïmplementeerd in onze kantoor- en cloudomgevingen. DDoS-mogelijkheden worden geleverd door onze internetprovider.

De prestaties van onze firewalls worden ook regelmatig beoordeeld aan de hand van onze programma's voor kwetsbaarheidsbeoordelingen (https://www.atlassian.com/trust/security/vulnerability-management) en penetratietests (https://www.atlassian.com/trust/security/security-testing) .

6.03.04. (e)

Kan een op de host gebaseerde inbraakpreventieservice (IPS) uitgevoerd worden in een virtuele installatie?

Dit is niet van toepassing, aangezien Atlassian een Software as a Service (SaaS)-model hanteert.

6.03.05.

Over het algemeen zijn PaaS-serviceproviders verantwoordelijk voor de beveiliging van de platformsoftwarestack, en de aanbevelingen in dit document vormen een goede basis om ervoor te zorgen dat een PaaS-provider rekening houdt met de beveiligingsprincipes bij het ontwerpen en beheren van zijn PaaS-platform. Het is vaak moeilijk om gedetailleerde informatie te verkrijgen van PaaS-providers over hoe ze hun platforms precies beveiligen. De volgende vragen kunnen echter, samen met andere secties in dit document, helpen bij het beoordelen van hun aanbod.

6.03.05. (a)

Vraag informatie aan over hoe applicaties voor meerdere tenants van elkaar worden geïsoleerd. Dit vereist een gedetailleerde omschrijving van de inperkings- en isolatiemaatregelen.

Dit is niet van toepassing, aangezien Atlassian een Software as a Service (SaaS)-model hanteert.

6.03.05. (b)

Welke garantie kan de PaaS-provider bieden dat toegang tot je gegevens beperkt is tot je zakelijke gebruikers en tot de applicaties die je bezit?

Dit is niet van toepassing, aangezien Atlassian een Software as a Service (SaaS)-model hanteert.

6.03.05. (c)

De platformarchitectuur zou een klassieke 'sandbox' moeten zijn. Zorgt de provider ervoor dat de PaaS-platformsandbox wordt gecontroleerd op nieuwe bugs en kwetsbaarheden?

Dit is niet van toepassing, aangezien Atlassian een Software as a Service (SaaS)-model hanteert.

6.03.05. (d)

PaaS-providers zouden verschillende beveiligingsfuncties moeten kunnen aanbieden (die door hun klanten kunnen worden hergebruikt). Omvatten deze gebruikersauthenticatie, eenmalige aanmelding, autorisatie (beheer van bevoegdheden) en SSL/TLS (beschikbaar gesteld door een API)?

Dit is niet van toepassing, aangezien Atlassian een Software as a Service (SaaS)-model hanteert.

6.03.06.

Het SaaS-model schrijft voor dat de provider alle applicaties beheert die aan eindgebruikers worden geleverd. Daarom zijn SaaS-providers voornamelijk verantwoordelijk voor de beveiliging van deze applicaties. Klanten zijn normaal gesproken verantwoordelijk voor operationele beveiligingsprocessen (gebruikers- en toegangsbeheer). De volgende vragen, samen met andere onderdelen in dit document, kunnen echter helpen bij het beoordelen van hun aanbod:

6.03.06. (a)

Welke beheerderscontroles zijn er en kunnen deze worden gebruikt om lees- en schrijfrechten toe te wijzen aan andere gebruikers.

Klanten van ons Enterprise- en Premium Cloud-aanbod hebben toegang tot een gecentraliseerd beheerpaneel. De beheerders van je organisatie kunnen de gebruikerstoegang en -rechten beheren voor al je productinstallaties. Bekijk hier onze blogpost: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Klanten van Atlassian kunnen de door hen gekozen externe identiteitsprovider gebruiken, indien ondersteund door Atlassian. Op een Atlassian-supportpagina vind je informatie over deze functies en hoe je verbinding kunt maken met de door jou gekozen identiteitsprovider, zie: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.06. (b)

Is de SaaS-toegangscontrole verfijnd en kan deze worden aangepast aan het beleid van je organisatie?

Klanten van ons Enterprise- en Premium Cloud-aanbod hebben toegang tot een gecentraliseerd beheerpaneel. De beheerders van je organisatie kunnen de gebruikerstoegang en -rechten beheren voor al je productinstallaties. Bekijk hier onze blogpost: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Klanten van Atlassian kunnen de door hen gekozen externe identiteitsprovider gebruiken, indien ondersteund door Atlassian. Op een Atlassian-supportpagina vind je informatie over deze functies en hoe je verbinding kunt maken met de door jou gekozen identiteitsprovider, zie: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.07. (a)

In geval van overbelasting van middelen (verwerking, geheugen, opslag, netwerk)?

• Welke informatie wordt gegeven over de relatieve prioriteit die aan mijn aanvraag wordt toegekend in geval van een fout in de voorziening?
• Is er een doorlooptijd voor wat betreft het serviceniveau en wijzigingen in de vereisten?
<

Atlassian plant zijn capaciteit 6-12 maanden van tevoren en strategische planning op hoog niveau duurt 36 maanden.

Atlassian onderhoudt analyses voor Cloud AWS en Azure scaling-in en scaling-out architectuur en gebruikt deze gegevens voor de mogelijke groei van Atlassian-producten. Deze gegevens worden op dit moment echter niet aan klanten verstrekt.

6.03.07. (b)

Hoeveel kun je opschalen? Biedt de aanbieder binnen een minimumperiode garanties voor de maximaal beschikbare middelen?

Atlassian plant zijn capaciteit 6-12 maanden van tevoren en strategische planning op hoog niveau duurt 36 maanden.

Atlassian onderhoudt analyses voor Cloud AWS en Azure scaling-in en scaling-out architectuur en gebruikt deze gegevens voor de mogelijke groei van Atlassian-producten. Deze gegevens worden op dit moment echter niet aan klanten verstrekt.

6.03.07. (c)

Hoe snel kun je opschalen? Biedt de aanbieder garanties over de beschikbaarheid van aanvullende middelen binnen een minimumperiode?

Atlassian plant zijn capaciteit 6-12 maanden van tevoren en strategische planning op hoog niveau duurt 36 maanden.

Atlassian onderhoudt analyses voor Cloud AWS en Azure scaling-in en scaling-out architectuur en gebruikt deze gegevens voor de mogelijke groei van Atlassian-producten. Deze gegevens worden op dit moment echter niet aan klanten verstrekt.

6.03.07. (d)

Welke processen zijn er voor het verwerken van grootschalige trends in het gebruik van middelen (bijv. seizoenseffecten)?

Atlassian plant zijn capaciteit 6-12 maanden van tevoren en strategische planning op hoog niveau duurt 36 maanden.

Atlassian onderhoudt analyses voor Cloud AWS en Azure scaling-in en scaling-out architectuur en gebruikt deze gegevens voor de mogelijke groei van Atlassian-producten. Deze gegevens worden op dit moment echter niet aan klanten verstrekt.

6.04.01.

De volgende controles zijn van toepassing op de identiteits- en toegangsbeheersystemen van de cloudprovider (de systemen die onder hun controle staan).

6.04.01. (a)

Hebben accounts systeembrede rechten voor het hele cloudsysteem en, zo ja, voor welke bewerkingen (lezen/schrijven/verwijderen)?

Ons wereldwijde supportteam handhaaft een account op alle gehoste systemen en applicaties voor onderhoud en support. Dit supportteam heeft uitsluitend toegang tot gehoste applicaties en gegevens om gezondheidscontroles en onderhoudswerkzaamheden aan systemen of applicaties uit te voeren, en op aanvraag van de klant via ons supportsysteem.

6.04.01. (b)

Hoe worden de accounts met de hoogste rechten geverifieerd en beheerd?

Atlassian handhaaft beperkingen voor het personeel dat deze toegang nodig heeft voor hun functie en verantwoordelijkheden. Alle niveau 1-systemen worden beheerd via de centrale eenmalige aanmelding (SSO) en mapoplossing van Atlassian. Gebruikers krijgen de juiste toegangsrechten op basis van deze profielen, aangestuurd via de workflow van ons HR-beheersysteem. Atlassian maakt gebruik van MFA voor toegang tot alle niveau 1-systemen. We hebben tweevoudige authenticatie mogelijk gemaakt voor de hypervisorbeheerconsole en de AWS-API, en geven een dagelijks auditrapport uit over alle toegang tot de hypervisorbeheerfuncties. De toegangslijsten voor de hypervisorbeheerconsole en de AWS-API worden elk kwartaal herzien. We zorgen ook voor een synchronisatie van elke 8 uur tussen ons HR-systeem en ons identiteitsarchief.

6.04.01. (c)

Hoe worden de meest cruciale beslissingen (bijv. gelijktijdige deregistratie van grote middelenblokken) geautoriseerd (enkel of dubbel, en volgens welke rollen binnen de organisatie)?

Atlassian handhaaft beperkingen voor het personeel dat deze toegang nodig heeft voor hun functie en verantwoordelijkheden. Alle niveau 1-systemen worden beheerd via de centrale eenmalige aanmelding (SSO) en mapoplossing van Atlassian. Gebruikers krijgen de juiste toegangsrechten op basis van deze profielen, aangestuurd via de workflow van ons HR-beheersysteem. Atlassian maakt gebruik van MFA voor toegang tot alle niveau 1-systemen. We hebben tweevoudige authenticatie mogelijk gemaakt voor de hypervisorbeheerconsole en de AWS-API, en geven een dagelijks auditrapport uit over alle toegang tot de hypervisorbeheerfuncties. De toegangslijsten voor de hypervisorbeheerconsole en de AWS-API worden elk kwartaal herzien. We zorgen ook voor een synchronisatie van elke 8 uur tussen ons HR-systeem en ons identiteitsarchief.

Voor onze kernproducten zijn er controles op het gebied van functiescheiding, waaronder, maar niet beperkt tot:

• Beoordelingen van toegangsbeheer
• Beveiligingsgroepen die door HR-applicaties worden beheerd
• Goedkeuring van wijziging/peerreview/implementatie (PRGB)
• Workflowcontroles

6.04.01. (d)

Zijn er rollen met hoge bevoegdheid toegewezen aan dezelfde persoon? Is deze toewijzing in strijd met de regels voor functiescheiding of de regels voor de minste bevoegdheid?

Atlassian handhaaft beperkingen voor het personeel dat deze toegang nodig heeft voor hun functie en verantwoordelijkheden. Alle niveau 1-systemen worden beheerd via de centrale eenmalige aanmelding (SSO) en mapoplossing van Atlassian. Gebruikers krijgen de juiste toegangsrechten op basis van deze profielen, aangestuurd via de workflow van ons HR-beheersysteem. Atlassian maakt gebruik van MFA voor toegang tot alle niveau 1-systemen. We hebben tweevoudige authenticatie mogelijk gemaakt voor de hypervisorbeheerconsole en de AWS-API, en geven een dagelijks auditrapport uit over alle toegang tot de hypervisorbeheerfuncties. De toegangslijsten voor de hypervisorbeheerconsole en de AWS-API worden elk kwartaal herzien. We zorgen ook voor een synchronisatie van elke 8 uur tussen ons HR-systeem en ons identiteitsarchief.

Voor onze kernproducten zijn er controles op het gebied van functiescheiding, waaronder, maar niet beperkt tot:

• Beoordelingen van toegangsbeheer
• Beveiligingsgroepen die door HR-applicaties worden beheerd
• Goedkeuring van wijziging/peerreview/implementatie (PRGB)
• Workflowcontroles

6.04.01. (e)

Gebruik je toegangsbeheer op basis van rollen (RBAC)? Wordt het principe van minste bevoegdheid gevolgd?

Atlassian heeft een vaste workflow die ons HR-managementsysteem koppelt aan ons systeem voor het inrichten van toegang. We gebruiken toegangsbeheer op basis van rollen gebaseerd op vooraf gedefinieerde gebruikersprofielen. Alle gebruikersaccounts moeten door het management goedgekeurd zijn voordat ze toegang krijgen tot gegevens, applicaties, infrastructuur of netwerkcomponenten.

Atlassian hanteert beperkingen voor het personeel dat toegang nodig heeft tot onze systemen, applicaties en infrastructuur voor hun functie en verantwoordelijkheden, op basis van de minste bevoegdheden, en dit wordt afgedwongen door middel van onze authenticatieprocessen.

6.04.01. (f)

Welke wijzigingen, indien van toepassing, worden aangebracht in de beheerdersrechten en -rollen om buitengewone toegang mogelijk te maken in geval van nood?

Ons wereldwijde supportteam handhaaft een account op alle gehoste systemen en applicaties voor onderhoud en support. Dit supportteam heeft uitsluitend toegang tot gehoste applicaties en gegevens om gezondheidscontroles en onderhoudswerkzaamheden aan systemen of applicaties uit te voeren, en op aanvraag van de klant via ons supportsysteem.

6.04.01. (g)

Is er een 'beheerdersrol' voor de klant? Speelt de klantenbeheerder bijvoorbeeld een rol bij het toevoegen van nieuwe gebruikers (maar zonder hem toe te staan de onderliggende opslag te wijzigen!)?

Atlassian biedt klanten de rol van 'organisatiebeheerder' die gebruikers en groepen voor de producten van de klanten beheert. Ga voor meer informatie naar: https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.02. (a)

Welke controles worden bij de registratie uitgevoerd voor de identiteit van gebruikersaccounts? Worden er normen gevolgd? Bijvoorbeeld het e-Government Interoperability Framework?

• Zijn er verschillende niveaus van identiteitscontroles op basis van de benodigde middelen?

Wereldwijd worden nieuwe Atlassians verplicht om een antecedentenonderzoek te ondergaan. Bij nieuwe werknemers als gevolg van een acquisitie wordt na de acquisitiedatum een antecedentenonderzoek uitgevoerd. Bij alle nieuwe werknemers en onafhankelijke contractanten wordt een strafrechtelijke controle uitgevoerd. Er worden ook opleidingsverificatie, tewerkstellingsverificatie of kredietcontroles toegevoegd als de functie of het niveau van de functie dat vereist. We voeren volledige antecedentenonderzoeken uit voor leidinggevende en boekhoudkundige functies.

Atlassian heeft een vaste workflow die ons HR-managementsysteem koppelt aan ons systeem voor het inrichten van toegang. We gebruiken toegangsbeheer op basis van rollen gebaseerd op vooraf gedefinieerde gebruikersprofielen. Alle gebruikersaccounts moeten door het management goedgekeurd zijn voordat ze toegang krijgen tot gegevens, applicatie, infrastructuur of netwerkonderdelen.

6.04.02. (b)

Welke processen zijn er om toegangsgegevens te deregistreren?

Ons proces van deregistratie omvat momenteel de beëindiging van een dienstverband, contract of overeenkomst. Gebruikers die intern overstappen behouden over het algemeen hun toegangsrechten om voortdurende betrokkenheid en support mogelijk te maken. Om een zeer responsief en flexibel klantgericht team te kunnen bieden, in lijn met onze bedrijfswaarden, ligt onze focus op het opsporen van ongeoorloofd gebruik van toegang in plaats van op het beperken van toegang, wat ons reactievermogen kan vertragen.

6.04.02. (c)

Worden toegangsgegevens in het hele cloudsysteem tegelijkertijd voorzien en gederegistreerd, of zijn er risico's verbonden aan het deregistreren van gegevens op meerdere geografisch verspreide locaties?

Atlassian heeft een vaste workflow die ons HR-managementsysteem koppelt aan ons systeem voor het inrichten van toegang. We gebruiken toegangsbeheer op basis van rollen gebaseerd op vooraf gedefinieerde gebruikersprofielen. Alle gebruikersaccounts moeten door het management goedgekeurd zijn voordat ze toegang krijgen tot gegevens, applicaties, infrastructuur of netwerkcomponenten.

Onze HR-applicatie wordt elke 8 uur gesynchroniseerd met onze interne Identity Store, waarbij alle accounts worden verwijderd van werknemers of contractanten die niet langer in dienst zijn.

6.04.03. (a)

Welke controles op het gebied van gegevensopslag en -beveiliging zijn van toepassing op de gebruikersmap (bijvoorbeeld AD, LDAP) en de toegang daartoe?

Gegevens worden geclassificeerd en behandeld in overeenstemming met ons beleid inzake informatielevenscyclus en gegevensbeveiliging, en op basis daarvan worden er controles geïmplementeerd. Ga voor meer informatie naar: https://www.atlassian.com/trust/security/security-practices

Alle systemen en projecten worden onderworpen aan een impactbeoordeling met betrekking tot PII. Onze overeenkomsten voor derden van Atlassian bevatten beveiligings- en privacybepalingen, voor zover van toepassing. Nieuwe leveranciers bij Atlassian moeten in onze contracten instemmen met ons privacy- en veiligheidsbeleid.

Atlassian is ISO-gecertificeerd voor een aantal producten. Dit vereist regelmatige risicobeoordelingen en beoordelingen van datapraktijken.

Onze gegevensbeschermingseffectbeoordeling is te vinden op: https://www.atlassian.com/legal/data-transfer-impact-assessment

Atlassian hanteert een standaard voor gegevensbehoud en -vernietiging, die aangeeft hoe lang we nodig hebben om verschillende soorten gegevens te bewaren. Gegevens worden geclassificeerd in overeenstemming met ons Atlassian-beleid inzake gegevensbeveiliging en levenscyclus van informatie, en op basis daarvan worden controles geïmplementeerd.

Voor klantgegevens: na beëindiging van een Atlassian-contract worden de gegevens van een klantenteam verwijderd uit de live productiedatabase en worden alle bestandsbijlagen die rechtstreeks naar Atlassian zijn geüpload binnen 14 dagen verwijderd. De gegevens van het team blijven in versleutelde back-ups staan totdat de bewaartermijn van 90 dagen voor back-ups vervalt. Daarna worden de gegevens vernietigd in overeenstemming met ons Atlassian-beleid voor gegevensbehoud. In het geval dat een databaseherstel nodig is binnen 90 dagen na het verwijderen van de gevraagde gegevens, zal het operationele team de gegevens zo snel als redelijkerwijs mogelijk opnieuw verwijderen nadat het live productiesysteem volledig is hersteld. Ga voor meer informatie naar https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

6.04.03. (b)

Zijn gegevens van gebruikersmappen exporteerbaar in een interoperabel formaat?

Beheerders kunnen de map met gebruikers exporteren via het beheerderspaneel. Handleidingen zijn hier beschikbaar op de supportsite van Atlassian: https://support.atlassian.com/organization-administration/docs/export-users-from-a-site/

6.04.03. (c)

Is need-to-know de basis voor toegang tot klantgegevens binnen de cloudprovider?

Atlassian handhaaft beperkingen voor het personeel dat deze toegang nodig heeft voor hun functie en verantwoordelijkheden. Alle niveau 1-systemen worden beheerd via de centrale eenmalige aanmelding (SSO) en mapoplossing van Atlassian. Gebruikers krijgen de juiste toegangsrechten op basis van deze profielen, aangestuurd via de workflow van ons HR-beheersysteem. Atlassian maakt gebruik van MFA voor toegang tot alle niveau 1-systemen. We hebben tweevoudige authenticatie mogelijk gemaakt voor de hypervisorbeheerconsole en de AWS-API, en geven een dagelijks auditrapport uit over alle toegang tot de hypervisorbeheerfuncties. De toegangslijsten voor de hypervisorbeheerconsole en de AWS-API worden elk kwartaal herzien. We zorgen ook voor een synchronisatie van elke 8 uur tussen ons HR-systeem en ons identiteitsarchief.

Voor onze kernproducten zijn er controles op het gebied van functiescheiding, waaronder, maar niet beperkt tot:

• Beoordelingen van toegangsbeheer
• Beveiligingsgroepen die door HR-applicaties worden beheerd
• Goedkeuring van wijziging/peerreview/implementatie (PRGB)
• Workflowcontroles

6.04.04.

Voor codes die onder controle staan van de cloudprovider:

6.04.04. (a)

Zijn er veiligheidscontroles om die codes te lezen en te schrijven? Bijvoorbeeld een sterk wachtwoordbeleid, codes opgeslagen in een apart systeem, hardwarebeveiligingsmodules (HSM) voor hoofdcertificeringscodes, authenticatie op basis van smartcards, directe afgeschermde toegang tot opslag, korte levensduur van codes, enz.

Atlassian hanteert een beleid voor versleuteling en cryptografie en implementatierichtlijnen. Dit beleid wordt jaarlijks herzien en bijgewerkt in overeenstemming met ons Policy Management Program (PMP). Ga voor meer informatie over onze PMP naar: https://www.atlassian.com/trust/security/security-management-program.

Atlassian onderhoudt gedocumenteerde procedures voor codebeheer voor onze cloudinfrastructuur. Versleutelingscodes voor Amazon-bijlagen, opgeslagen in S3, worden beheerd door Amazon KMS. Het proces van versleuteling, codebeheer en ontsleuteling wordt regelmatig intern geïnspecteerd en geverifieerd door Amazon als onderdeel van hun bestaande auditproces. Door Atlassian beheerde codes worden geroteerd als er relevante wijzigingen van rollen of gebruiksstatus plaatsvinden. AWS KMS Service voldoet aan SOC 1, SOC 2 en SOC 3. Ga voor meer informatie naar: https://aws.amazon.com/kms/

6.04.04. (b)

Zijn er beveiligingsmaatregelen getroffen om die codes te gebruiken om gegevens te ondertekenen en te versleutelen?

Atlassian onderhoudt gedocumenteerde procedures voor codebeheer voor onze cloudinfrastructuur. Versleutelingscodes voor Amazon-bijlagen, opgeslagen in S3, worden beheerd door Amazon KMS. Het proces van versleuteling, codebeheer en ontsleuteling wordt regelmatig intern geïnspecteerd en geverifieerd door Amazon als onderdeel van hun bestaande auditproces. Mastercodes binnen KMS maken bij de aanmaak een automatische roulatie mogelijk om elke 365 dagen (jaarlijks) hoofdcodes te genereren.

6.04.04. (c)

Bestaan er procedures in geval van een sleutel-compromis? Bijvoorbeeld lijsten met intrekkingen voor sleutels.

Atlassian onderhoudt gedocumenteerde procedures voor sleutelbeheer voor onze Cloud-infrastructuur. Encryptiesleutels voor Amazon-bijlagen, die zijn opgeslagen in S3, worden beheerd door Amazon KMS. De processen voor versleuteling, sleutelbeheer en ontsleuteling worden regelmatig intern geïnspecteerd en geverifieerd door Amazon als onderdeel van hun bestaande auditproces. Door Atlassian beheerde sleutels worden geroteerd als er relevante veranderingen van rollen of gebruiksstatus plaatsvinden. AWS KMS Service voldoet aan SOC 1, SOC 2 en SOC 3. Ga voor meer informatie naar: https://aws.amazon.com/kms/

6.04.04. (c)

Bestaan er procedures in geval van een sleutel-compromis? Bijvoorbeeld lijsten met intrekkingen voor sleutels.

Atlassian onderhoudt gedocumenteerde procedures voor sleutelbeheer voor onze Cloud-infrastructuur. Encryptiesleutels voor Amazon-bijlagen, die zijn opgeslagen in S3, worden beheerd door Amazon KMS. De processen voor versleuteling, sleutelbeheer en ontsleuteling worden regelmatig intern geïnspecteerd en geverifieerd door Amazon als onderdeel van hun bestaande auditproces. Door Atlassian beheerde sleutels worden geroteerd als er relevante veranderingen van rollen of gebruiksstatus plaatsvinden. AWS KMS Service voldoet aan SOC 1, SOC 2 en SOC 3. Ga voor meer informatie naar: https://aws.amazon.com/kms/

6.04.04. (d)

Is het mogelijk om gelijktijdigheidsproblemen op meerdere sites op te lossen met de intrekking van sleutels?

Atlassian onderhoudt gedocumenteerde procedures voor sleutelbeheer voor onze Cloud-infrastructuur. Encryptiesleutels voor Amazon-bijlagen, die zijn opgeslagen in S3, worden beheerd door Amazon KMS. De processen voor versleuteling, sleutelbeheer en ontsleuteling worden regelmatig intern geïnspecteerd en geverifieerd door Amazon als onderdeel van hun bestaande auditproces. Door Atlassian beheerde sleutels worden geroteerd als er relevante veranderingen van rollen of gebruiksstatus plaatsvinden. AWS KMS Service voldoet aan SOC 1, SOC 2 en SOC 3. Ga voor meer informatie naar: https://aws.amazon.com/kms/

6.04.04. (e)

Zijn de afbeeldingen van het klantensysteem beschermd of versleuteld?

Atlassian gebruikt de industriestandaard Transport Layer Security ('TLS') versie 1.2 om een veilige verbinding tot stand te brengen met behulp van 256-­bits Advanced Encryption Standard ('AES')-versleuteling. Servers die gebruikersgegevens bevatten, gebruiken de toonaangevende AES-versleuteling voor volledige schijf. Tenant-gegevens worden versleuteld in de AWS RDS- of RDS-back-ups en worden ook versleuteld in langdurige opslag (S3) en in alle bijlagen. Ga voor meer informatie naar https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management

Alle klantgegevens in Atlassian-cloudproducten en -services worden met behulp van Transport Layer Security (TLS) 1.2+ met Perfect Forward Secrecy (PFS) onderweg versleuteld bij openbare netwerken. Zo wordt ongeautoriseerde openbaarmaking of verandering voorkomen. Dankzij onze implementatie van TLS zijn sterke versleuteling en sleutellengtes verplicht, waar deze ondersteund worden door de browser.

Harde schijven op servers die klantgegevens en bijlagen bevatten in Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie en Trello gebruiken de standaard AES-256-versleuteling voor de volledige schijf in rust.

Voor versleuteling in rust versleutelen we met name klantgegevens die op een schijf zijn opgeslagen, zoals gegevens van Jira-issues (details, opmerkingen, bijlagen) of gegevens van de Confluence-pagina's (pagina-inhoud, opmerkingen, bijlagen). Gegevensversleuteling in rust biedt bescherming tegen ongeautoriseerde toegang en zorgt ervoor dat gegevens alleen toegankelijk zijn voor geautoriseerde functies en diensten met gecontroleerde toegang tot de versleutelingscodes.

6.04.05. (a)

Versleuteling kan op meerdere plaatsen worden gebruikt. Waar wordt dit gebruikt?

• Gegevens onderweg?
• Gegevens in rust?
• Gegevens in de processor of in het geheugen?

Atlassian hanteert een beleid voor versleuteling en cryptografie en implementatierichtlijnen. Dit beleid wordt jaarlijks herzien en bijgewerkt in overeenstemming met ons Policy Management Program (PMP). Ga voor meer informatie naar: https://www.atlassian.com/trust/security/security-management-program .

Atlassian onderhoudt gedocumenteerde procedures voor sleutelbeheer voor onze Cloud-infrastructuur. Encryptiesleutels voor Amazon-bijlagen, die zijn opgeslagen in S3, worden beheerd door Amazon KMS. De processen voor versleuteling, sleutelbeheer en ontsleuteling worden regelmatig intern geïnspecteerd en geverifieerd door Amazon als onderdeel van hun bestaande auditproces. Door Atlassian beheerde sleutels worden geroteerd als er relevante veranderingen van rollen of gebruiksstatus plaatsvinden. Alle klantgegevens in Atlassian-cloudproducten en -services worden met behulp van Transport Layer Security (TLS) 1.2+ met Perfect Forward Secrecy (PFS) onderweg versleuteld bij openbare netwerken. Zo wordt onbevoegde openbaarmaking of verandering voorkomen. Dankzij onze implementatie van TLS zijn sterke versleuteling en sleutellengtes verplicht, waar deze ondersteund worden door de browser.

Harde schijven op servers die klantgegevens en bijlagen bevatten in Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie en Trello gebruiken de standaard AES-256-versleuteling voor de volledige schijf in rust.

Voor versleuteling in rust versleutelen we met name klantgegevens die op een schijf zijn opgeslagen, zoals gegevens van Jira-issues (details, opmerkingen, bijlagen) of gegevens van de Confluence-pagina's (pagina-inhoud, opmerkingen, bijlagen). Gegevensversleuteling in rust biedt bescherming tegen ongeautoriseerde toegang en zorgt ervoor dat gegevens alleen toegankelijk zijn voor geautoriseerde functies en diensten met gecontroleerde toegang tot de versleutelingscodes.

6.04.05. (b)

Is er een duidelijk omschreven beleid voor wat wel en niet versleuteld moet worden?

Atlassian hanteert een beleid voor versleuteling en cryptografie en implementatierichtlijnen. Dit beleid wordt jaarlijks herzien en bijgewerkt in overeenstemming met ons Policy Management Program (PMP). Ga voor meer informatie over onze PMP naar: https://www.atlassian.com/trust/security/security-management-program.

Atlassian onderhoudt gedocumenteerde procedures voor sleutelbeheer voor onze Cloud-infrastructuur. Encryptiesleutels voor Amazon-bijlagen, die zijn opgeslagen in S3, worden beheerd door Amazon KMS. Het proces van versleuteling, codebeheer en ontsleuteling wordt regelmatig intern geïnspecteerd en geverifieerd door Amazon als onderdeel van hun bestaande auditproces. Door Atlassian beheerde sleutels worden geroteerd als er relevante veranderingen van rollen of gebruiksstatus plaatsvinden.

6.04.05. (d)

Wie is de eigenaar van de toegangssleutels?

Atlassian gebruikt de AWS Key Management Service (KMS) voor sleutelbeheer. De processen voor versleuteling, ontsleuteling en sleutelbeheer worden regelmatig intern geïnspecteerd en geverifieerd door AWS als onderdeel van hun bestaande interne validatieprocessen. Er wordt een eigenaar toegewezen aan iedere sleutel. Deze eigenaar is er verantwoordelijk voor dat het juiste niveau van beveiligingscontroles wordt toegepast op de sleutels.

6.04.05. (e)

Hoe worden de sleutels beschermd?

Atlassian gebruikt de AWS Key Management Service (KMS) voor sleutelbeheer. De processen voor versleuteling, ontsleuteling en sleutelbeheer worden regelmatig intern geïnspecteerd en geverifieerd door AWS als onderdeel van hun bestaande interne validatieprocessen. Er wordt een eigenaar toegewezen aan iedere sleutel. Deze eigenaar is er verantwoordelijk voor dat het juiste niveau van beveiligingscontroles wordt toegepast op de sleutels.

6.04.06. (a)

Welke vormen van authenticatie worden gebruikt voor operaties die een hoge mate van zekerheid vereisen? Dit kan bestaan uit inloggen op de beheerinterfaces, het aanmaken van sleutels, toegang tot accounts voor meerdere gebruikers, firewallconfiguratie, toegang op afstand, enz.

• Wordt tweefactorauthenticatie gebruikt om kritieke componenten binnen de infrastructuur te beheren, zoals firewalls, enz.?

We volgen de richtlijnen zoals beschreven in de speciale publicatie 800-63B van NIST. Zie: https://pages.nist.gov/800-63-3/sp800-63b.html

Het proces voor het toewijzen van wachtwoorden wordt behandeld in het Wachtwoordenbeleid van Atlassian. Nieuwe wachtwoorden worden niet elektronisch doorgegeven, behalve in gevallen waarin een eerste eenmalig wachtwoord wordt verzonden. In deze gevallen wordt de gebruiker gedwongen om het eenmalige wachtwoord te veranderen wanneer het voor het eerst wordt gebruikt.

In het algemeen worden controles met betrekking tot toegangscontrole behandeld in het Toegangsbeheerbeleid, waarvan een uittreksel hier beschikbaar is: https://www.atlassian.com/trust/security/ismp-policies

Atlassian hanteert beperkingen voor het personeel dat toegang nodig heeft tot onze systemen, applicaties en infrastructuur voor hun functie en verantwoordelijkheden, op basis van de minste bevoegdheden. Dit wordt afgedwongen door middel van onze authenticatieprocessen. Alle toegang gaat via geverifieerde sessies en is gebaseerd op vastgestelde rechten.

Atlassian handhaaft beperkingen voor het personeel dat deze toegang nodig heeft voor hun functie en verantwoordelijkheden. Alle niveau 1-systemen worden beheerd via de centrale directory-oplossing van Atlassian voor eenmalige aanmelding (SSO). Gebruikers krijgen de juiste toegangsrechten op basis van deze profielen, aangestuurd via de workflow van ons HR-beheersysteem. Atlassian maakt gebruik van MFA voor toegang tot alle niveau 1-systemen. We hebben tweefactorauthenticatie mogelijk gemaakt voor de hypervisorbeheerconsole en de AWS-API, en we geven een dagelijks auditrapport uit over alle toegang tot de hypervisorbeheerfuncties. De toegangslijsten voor de hypervisorbeheerconsole en de AWS-API worden elk kwartaal herzien. We zorgen ook voor een synchronisatie van elke 8 uur tussen ons HR-systeem en ons identiteitsarchief.

6.04.07. (a)

Bied je afwijkingsdetectie aan (de mogelijkheid om ongebruikelijk en mogelijk schadelijk IP-verkeer en gedrag van gebruikers of ondersteuningsteams te herkennen)? Bijvoorbeeld een analyse van mislukte en succesvolle aanmeldingen, aanmeldingen op ongebruikelijke tijdstippen en meerdere aanmeldingen na elkaar, enz.

Ons Atlassian Cloud Platform heeft heel weinig oppervlakte dat door de firewalls wordt blootgesteld. We herzien de firewall-regels periodiek. We hebben IDS geïmplementeerd op onze kantoorlocaties en in onze cloudhostingomgeving. Voor het Atlassian Cloud Platform kan het doorsturen van logs geïntegreerd worden met een platform voor beveiligingsanalyse. Op containerniveau van het Cloud Platform wordt de bestandsintegriteit gehandhaafd omdat de installaties niet kunnen worden aangepast. Atlassian Network Engineering maakt gebruik van IPS-technologieën die zijn ingebouwd in onze firewalls. Ook hebben we IDS-technologieën geïmplementeerd in onze kantoor- en cloudomgevingen. DDoS-mogelijkheden worden geleverd door onze internetprovider.

Sleutelsysteemlogs worden vanaf elk systeem doorgestuurd naar een gecentraliseerd logplatform, waar logs alleen gelezen kunnen worden. Het Beveiligingsteam van Atlassian maakt waarschuwingen aan op ons platform voor beveiligingsanalyses (Splunk) en controleert op tekenen van schade. Onze SRE-teams gebruiken het platform om te controleren op problemen met beschikbaarheid of prestaties. Logboeken worden 30 dagen bewaard in de hot back-up en 365 dagen in de cold back-up.

6.04.07. (b)

Welke voorzieningen zijn er in geval van diefstal van de toegangsgegevens van een klant (detectie, intrekking, bewijs voor acties)?

In het kader van de Atlassian Cloud-services zijn onze klanten mogelijk verantwoordelijk voor sommige of alle aspecten van het toegangsbeheer voor de gebruikers van de services die zij beheren.

Atlassian stelt onze klanten dan ook in staat om de toegang te beheren voor gebruikers van de service die onder de controle van de klant valt, bijvoorbeeld door administratieve rechten te verlenen om de toegang te beheren of te beëindigen. Atlassian vergelijkt ook de toegangsgegevens van klanten met databanken met gelekte toegangsgegevens en dwingt gebruikers hun wachtwoord bij te werken.

Atlassian biedt niet rechtstreeks Data Loss Prevention (DLP) aan als onderdeel van de Cloud-implementaties. Er zijn echter verkopers op de Atlassian Marketplace, zoals Nightfall, die Atlassian aanbeveelt voor klanten die deze DLP-functionaliteit wensen. Bekijk hier de Marketplace-productpagina voor Nightfall: https://marketplace.atlassian.com/vendors/1217783/nightfall. Nightfall omvat het automatisch scannen van gevoelige informatie, waaronder toegangsgegevens, geheimen en API-sleutels.

Atlassian heeft Beacon gelanceerd, dat in de bètaversie beschikbaar is en DLP-functies toevoegt. Totdat Beacon ook buiten de bètaversie wordt gelanceerd, raadt Atlassian Nightfall nog steeds aan. Meer informatie over Atlassian Beacon vind je op: https://www.atlassian.com/software/beacon.

We hebben een gedocumenteerd beleid en plan voor Beveiligingsincidentrespons, waarvan de belangrijkste principes het volgende omvatten:

• Anticipeer op beveiligingsincidenten en bereid je voor op incidentrespons
• Werk aan het inperken, uitroeien en herstellen van incidenten
• Investeer in onze mensen, processen en technologieën om ervoor te zorgen dat we de mogelijkheid hebben om een beveiligingsincident te detecteren en te analyseren wanneer het zich voordoet
• Geef de bescherming van persoonsgegevens en klantgegevens de hoogste prioriteit tijdens beveiligingsincidenten
• Oefen regelmatig het responsproces voor beveiligingsincidenten
• Leer van en verbeter de functie voor het beheersen van beveiligingsincidenten
• Communiceer kritieke beveiligingsincidenten naar de Atlassian Leadership Group

6.04.08.

De volgende vragen zijn van toepassing op de identiteits- en toegangsbeheersystemen die door de cloudprovider worden aangeboden voor gebruik en controle door de Cloud-klant.

6.04.08.01. (a)

Maakt het systeem een gefedereerde IDM-infrastructuur mogelijk die interoperabel is voor zowel systemen met een hoge mate van zekerheid (OTP-systemen, waar nodig) als voor systemen met weinig zekerheid (bijv. gebruikersnaam en wachtwoord)?

Atlassian Access ondersteunt standaarden voor identiteitsfederatie in al onze Atlassian-producten (Confluence, Jira, Jira Align, Bitbucket, enz.). Atlassian Access kan automatisch je Active Directory synchroniseren met Atlassian via Okta, Azure, AD en Onelogin. Ga voor meer informatie naar: https://www.atlassian.com/enterprise/cloud/access. Specifieke SSO-instellingen voor producten (Algemene SAML v2.0, Google, Okta, OneLogin, PingIdentity, ADFS):

• Opsgenie ondersteunt meerdere SSO-providers. Zie: https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/ voor meer informatie
• Trello ondersteunt meerdere SSO-providers. Zie https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization voor meer informatie
• Statuspage ondersteunt meerdere SSO-providers. Zie https://help.statuspage.io/knowledge_base/categories/single-sign-on-2 voor meer informatie

6.04.08.01. (b)

Is de cloudprovider compatibel met externe identiteitsproviders?

Klanten van Atlassian kunnen de door hen gekozen externe identiteitsprovider gebruiken, indien deze wordt ondersteund door Atlassian. Op de Atlassian-supportpagina vind je informatie over deze functies en hoe je verbinding kunt maken met de door jou gekozen identiteitsprovider. Zie: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.04.08.01. (c)

Is er de mogelijkheid om eenmalige aanmelding toe te voegen?

Atlassian ondersteunt het gebruik van Google-, Microsoft- en Apple-ID's voor de authenticatie van de meeste producten. We ondersteunen ook SAML voor onze Atlassian Cloud-services via Atlassian Access. Zie: https://www.atlassian.com/enterprise/cloud/access.

6.04.08.02. (a)

Maakt het systeem voor klantentoegangsgegevens de scheiding mogelijk van rollen en verantwoordelijkheden en voor meerdere domeinen (of één enkele sleutel voor meerdere domeinen, rollen en verantwoordelijkheden)?

Atlassian is een SaaS-applicatie voor meerdere tenants. Het hebben van meerdere tenants is een belangrijk kenmerk van Atlassian Cloud waardoor meerdere klanten één installatie van de Jira- of Confluence-applicatielaag kunnen delen, terwijl de applicatiegegevens van elke tenant van de klant worden geïsoleerd. Atlassian Cloud doet dit via de Tenant Context Service (TCS). Elke gebruikers-ID is gekoppeld aan precies één tenant, die vervolgens wordt gebruikt voor toegang tot de Atlassian Cloud-applicaties. Ga voor meer informatie naar: https://www.atlassian.com/trust/security/security-practices#tenant-isolation

Klanten van ons Enterprise- en Premium Cloud-aanbod hebben toegang tot een gecentraliseerd beheerpaneel. De beheerders van je organisatie kunnen de gebruikerstoegang en -rechten beheren voor al je productinstallaties. Bekijk hier onze blogpost: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Atlassian biedt klanten de rol van 'organisatiebeheerder' die gebruikers en groepen voor de producten van de klanten beheert. Ga voor meer informatie naar: https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.08.02. (b)

Hoe beheer je de toegang tot systeemkopieën van klanten en hoe zorg je ervoor dat de authenticatie- en cryptografische sleutels er niet in staan?

Ons wereldwijde supportteam handhaaft een account op alle gehoste systemen en applicaties voor onderhoud en support. Dit supportteam heeft uitsluitend toegang tot gehoste applicaties en gegevens om gezondheidscontroles en onderhoudswerkzaamheden aan systemen of applicaties uit te voeren, en op aanvraag van de klant via ons supportsysteem.

6.04.08.03. (a)

Hoe identificeert de cloudprovider zichzelf bij de klant (dat wil zeggen, is er wederzijdse authenticatie)?

• Wanneer de klant API-opdrachten stuurt?
• Wanneer de klant inlogt op de beheerinterface?

Atlassian maakt gebruik van wederzijdse authenticatie om zichzelf te identificeren bij de klant. API-documentatie van Atlassian is te vinden op: https://developer.atlassian.com/cloud/. Het Atlassian Service Authentication Protocol (ASAP) is een service-to-service-authenticatieprotocol waarbij gebruik wordt gemaakt van een toegangstoken die is geïmplementeerd met behulp van JSON Web Token (JWT) en dat is ondertekend met een RSA-sleutel van een betrouwbare Atlassian-autoriteit. Zie Atlassian Service Authentication Protocol voor meer informatie. We maken geen gebruik van traditionele 'serviceaccounts'. We vertrouwen wel op authenticatie en autorisatie via Service to Service.

6.04.08.03. (b)

Steun je een verbonden authenticatiesysteem?

Atlassian Access ondersteunt standaarden voor identiteitsfederatie in al onze Atlassian-producten (Confluence, Jira, Jira Align, Bitbucket, enz.). Atlassian Access kan automatisch je Active Directory synchroniseren met Atlassian via Okta, Azure, AD en Onelogin. Ga voor meer informatie naar: https://www.atlassian.com/enterprise/cloud/access. Specifieke SSO-instellingen voor producten (Algemene SAML v2.0, Google, Okta, OneLogin, PingIdentity, ADFS):

• Opsgenie ondersteunt meerdere SSO-providers. Zie: https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/ voor meer informatie
• Trello ondersteunt meerdere SSO-providers. Zie https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization voor meer informatie
• Statuspage ondersteunt meerdere SSO-providers. Zie https://help.statuspage.io/knowledge_base/categories/single-sign-on-2 voor meer informatie

6.05.

Het is belangrijk om ervoor te zorgen dat de provider een actuele lijst bijhoudt van hardware- en software-assets (applicaties) die onder controle staan van de cloudprovider. Dit maakt het mogelijk om te controleren of op alle systemen de juiste controles zijn toegepast en of systemen niet als achterdeurtje naar de infrastructuur kunnen worden gebruikt.

6.05. (a)

Beschikt de provider over een geautomatiseerd middel om alle assets te inventariseren, wat het makkelijker maakt om ze op de juiste manier te beheren?

Onze productiesystemen bevinden zich in infrastructuur die wordt verkregen via cloudserviceproviders. Deze systemen worden niet op hardwareniveau bijgehouden vanwege de aard van de service. De onderliggende microservices waar onze producten op draaien worden bijgehouden in een speciaal gebouwde 'service'-database. Deze database wordt automatisch bijgewerkt wanneer een service geïmplementeerd wordt.

Ons technologieteam voor Workplace gebruikt onze eigen Jira Software om een assetinventaris bij te houden van alle eindpunten voor trackingdoeleinden.

6.05. (b)

Is er een lijst van assets die de klant gedurende een bepaalde periode heeft gebruikt?

Atlassian is een SaaS-applicatie voor meerdere tenants. Het hebben van meerdere tenants is een belangrijk kenmerk van Atlassian Cloud waardoor meerdere klanten één installatie van de Jira- of Confluence-applicatielaag kunnen delen, terwijl de applicatiegegevens van elke tenant van de klant worden geïsoleerd. Atlassian Cloud doet dit via de Tenant Context Service (TCS). Elke gebruikers-ID is gekoppeld aan precies één tenant, die vervolgens wordt gebruikt voor toegang tot de Atlassian Cloud-applicaties. Ga voor meer informatie naar: https://www.atlassian.com/trust/security/security-practices#tenant-isolation

De volgende vragen moeten worden gesteld wanneer de eindklant gegevens implementeert waarvoor extra bescherming nodig is (d.w.z. ze worden als gevoelig beschouwd).

6.05. (c)

Worden assets geclassificeerd op basis van gevoeligheid en belang?

• Zo ja, past de provider een passende scheiding toe tussen systemen met verschillende classificaties en voor één klant die systemen met verschillende veiligheidsclassificaties heeft?

Atlassian hanteert een beoordeling van 4 niveaus voor onze assets en services, waarbij de vereisten voor beschikbaarheid, serviceniveau en continuïteit per niveau worden vastgesteld. Zie https://www.atlassian.com/trust/security/data-management voor meer informatie.

6.06.

Deze reeks vragen moet worden overwogen om inzicht te krijgen in de risico's die verbonden zijn aan vendor lock-in.

6.06. (a)

Zijn er gedocumenteerde procedures en API's voor het exporteren van gegevens uit de cloud?

Klantgegevens zijn beschikbaar via de webapp en API. Details voor specifieke producten vind je hieronder.

• Confluence, Jira en Jira Align: Meer informatie over onze Atlassian API vind je op: https://developer.atlassian.com/cloud/jira/platform/rest/v3/
• Trello: bestuursgegevens zijn beschikbaar voor export door bestuursleden in JSON-formaat via de REST API van Trello. Bestandsbijlagen kunnen afzonderlijk rechtstreeks van Amazon S3 worden opgehaald met behulp van de unieke hyperlink van bestanden. De edities Trello Business Class en Enterprise bieden een vereenvoudigd proces voor gegevensexport voor alle organisatiegegevens en bijlagen. Elke Business Class- en Enterprise-organisatie bevat de optie tot het exporteren van alle borden binnen de organisatie met één klik. Bestandsbijlagen die rechtstreeks naar Trello worden geüpload, kunnen eventueel worden opgenomen in het exportbestand. In de export worden de gegevens van elk bord opgenomen in zowel JSON- als Comma Separated Values-formaat ('CSV').
• Opsgenie: De API is te vinden op: https://docs.opsgenie.com/docs/api-overview
• Statuspage: De API is te vinden op: https://doers.statuspage.io/api/v1/
• Bitbucket: Elke broncode of repo kan vanuit Bitbucket worden gedownload of geëxporteerd voor interoperabiliteitsdoeleinden. Zie: https://confluence.atlassian.com/bitbucket/does-bitbucket-backup-my-repositories-288658413.html
• Halp: heeft een CSV-exportfunctie. Je kunt hier meer documentatie lezen: https://plz.halp.com/article/5790zlyrun-export-to-csv

6.06. (b)

Biedt de leverancier interoperabele exportformaten voor alle gegevens die in de cloud zijn opgeslagen?

Atlassian faciliteert verzoeken van klanten om hun gegevens te exporteren, mochten die op Atlassian-producten worden gehost. Er zijn robuuste tools voor dataportabiliteit en gegevensbeheer beschikbaar voor het exporteren van product- en gebruikersgegevens. Voor meer informatie over de export van Atlassian Cloud-gegevens, zie onze import- en exportdocumentatie op: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Zie https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/ voor meer informatie over het exporteren van gegevens naar veelgebruikte formaten zoals CSV, HTML en XML.

6.06. (c)

In het geval van SaaS, worden de gebruikte API-interfaces gestandaardiseerd?

Details over onze Atlassian Cloud API's zijn te vinden op: https://developer.atlassian.com/explore-the-apis/

Specifieke API-gegevens voor het product:

• Trello: API-documentatie is beschikbaar op: https://developer.atlassian.com/cloud/trello
• Jira Align: API is te vinden op: https://help.jiraalign.com/hc/en-us/articles/360045371954-Getting-started-with-the-REST-API-2-0
• Statuspage: De API is te vinden op: https://doers.statuspage.io/api/v1
• Opsgenie: De API is te vinden op: https://docs.opsgenie.com/docs/api-overview
• Halp: heeft op dit moment geen openbare API.

6.06. (d)

Zijn er voorzieningen voor het exporteren van door gebruikers gemaakte applicaties in een standaardformaat?

Dit is niet van toepassing, aangezien Atlassian een Software as a Service (SaaS)-model hanteert.

6.06. (e)

Zijn er procedures om te testen of gegevens kunnen worden geëxporteerd naar een andere cloudprovider, bijvoorbeeld als de klant van provider wil veranderen?

Atlassian faciliteert verzoeken van klanten om hun gegevens te exporteren, mochten die op Atlassian-producten worden gehost. Er zijn robuuste tools voor dataportabiliteit en gegevensbeheer beschikbaar voor het exporteren van product- en gebruikersgegevens. Voor meer informatie over de export van Atlassian Cloud-gegevens, zie onze import- en exportdocumentatie op: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Zie https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/ voor meer informatie over het exporteren van gegevens naar veelgebruikte formaten zoals CSV, HTML en XML.

6.06. (f)

Kan de klant zelf gegevens extraheren om te controleren of het formaat universeel is en kan worden overgezet naar een andere cloudprovider?

Atlassian faciliteert verzoeken van klanten om hun gegevens te exporteren, mochten die op Atlassian-producten worden gehost. Er zijn robuuste tools voor dataportabiliteit en gegevensbeheer beschikbaar voor het exporteren van product- en gebruikersgegevens. Voor meer informatie over de export van Atlassian Cloud-gegevens, zie onze import- en exportdocumentatie op: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Zie https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/ voor meer informatie over het exporteren van gegevens naar veelgebruikte formaten zoals CSV, HTML en XML.

6.07.

Continuïteit bieden is belangrijk voor een organisatie. Hoewel het mogelijk is om service level agreements op te stellen waarin wordt beschreven hoe lang systemen minimaal beschikbaar zijn, blijven er nog een aantal aanvullende overwegingen over.

6.07. (a)

Hanteert de provider een gedocumenteerde methode die de gevolgen van een verstoring beschrijft?

• Wat zijn de RPO (Recovery Point Objective) en RTO (Recovery Time Objective) voor services? Details volgens het kritieke aspect van de service.
• Komen informatiebeveiligingsactiviteiten op gepaste wijze aan bod tijdens het herstelproces?
• Wat zijn de vormen van communicatie met eindklanten in geval van een storing?
• Zijn de rollen en verantwoordelijkheden van teams duidelijk omschreven in het geval van een verstoring?

Er is een beleid en een plan voor bedrijfscontinuïteit en disaster recovery van kracht; deze worden jaarlijks herzien door de stuurgroep voor Bedrijfscontinuïteit/Disaster recovery. Voor meer informatie (onder meer met betrekking tot RPO's, RTO's en veerkracht via het gebruik van beschikbaarheidszones), zie: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management en https://www.atlassian.com/trust/security/data-management.

De datacenters van onze partners beschikken over meerdere conformiteitscertificeringen. Deze certificeringen hebben betrekking op fysieke beveiliging, systeembeschikbaarheid, netwerk- en IP-backbone-toegang, klantprovisioning en probleembeheer. Toegang tot de datacenters wordt beperkt tot bevoegd personeel en gecontroleerd met biometrische identiteitscontroles. Fysieke beveiligingsmaatregelen omvatten: on-premise-bewakers, videobewaking met gesloten circuit, toegangssluizen en aanvullende maatregelen tegen inbraak. Informatie over de fysieke bescherming van AWS is te vinden op: http://aws.amazon.com/compliance/

6.07. (b)

Heeft de provider de priority voor herstel gecategoriseerd, en wat zou onze relatieve priority (de eindklant) zijn voor een herstel? Opmerking: dit kan een categorie zijn (HIGH/MED/LOW).

Eigenaren van bedrijfskritieke systemen en processen en service-eigenaren moeten zorgen voor goede bedrijfscontinuïteit en/of disaster recovery in overeenstemming met de tolerantie voor verstoring in geval van een ramp. De BCDR-plannen worden elk kwartaal getest en alle geïdentificeerde issues worden opgelost. Zie https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management en https://www.atlassian.com/trust/security/data-management voor meer informatie.

6.07. (c)

Welke afhankelijkheden zijn er die relevant zijn voor het herstelproces? Voeg leveranciers en outsource-partners toe.

Atlassian heeft een procedure voor, en een log van, pogingen om gegevens te herstellen. Op hoog niveau is dit vervat in onze interne Backups Standard en ons beleid voor Bedrijfscontinuïteit en Disaster Recovery. Voor elke Atlassian-service hebben we echter verschillende interne documenten, waaronder runbooks, planningen en procedures voor door de klant geïnitieerde herstelacties en door Atlassian geïnitieerde herstelwerkzaamheden.

6.07. (d)

In het geval dat de primaire locatie onbeschikbaar wordt gemaakt, wat is dan de minimale afstand voor de locatie van de secundaire locatie?

De datacenters van onze partners beschikken over meerdere conformiteitscertificaten. Deze certificeringen hebben betrekking op fysieke beveiliging, systeembeschikbaarheid, netwerk- en IP-backbone-toegang, klantprovisioning en probleembeheer. Toegang tot de datacenters wordt beperkt tot bevoegd personeel en gecontroleerd met biometrische identiteitscontroles. Fysieke beveiligingsmaatregelen omvatten: bewakers op locatie, videobewaking, toegangssluizen en aanvullende maatregelen voor inbraakbeveiliging. Informatie over de fysieke bescherming van AWS is te vinden op: http://aws.amazon.com/compliance/

6.07.01.

Incidentmanagement en -respons is een onderdeel van bedrijfscontinuïteitsbeheer. Het doel van dit proces is om de impact van onverwachte en mogelijk verstorende gebeurtenissen tot een aanvaardbaar niveau voor een organisatie te beperken. Om te evalueren in hoeverre een organisatie in staat is om de kans op een incident te verkleinen of de negatieve gevolgen van een informatiebeveiligingsincident te verminderen, moeten de volgende vragen worden gesteld aan een cloudprovider:

6.07.01. (a)

Heeft de provider een formeel proces om incidenten op te sporen, te identificeren, te analyseren en erop te reageren?

We hebben een gedocumenteerd beleid en plan voor Beveiligingsincidentrespons. De belangrijkste principes hiervan omvatten het volgende:

• Anticipeer op beveiligingsincidenten en bereid je voor op incidentrespons
• Werk aan het inperken, uitroeien en herstellen van incidenten
• Investeer in onze mensen, processen en technologieën om ervoor te zorgen dat we de mogelijkheid hebben om een beveiligingsincident te detecteren en te analyseren wanneer het zich voordoet
• Geef de bescherming van persoonsgegevens en klantgegevens de hoogste prioriteit tijdens beveiligingsincidenten
• Oefen regelmatig het responsproces voor beveiligingsincidenten
• Leer van en verbeter de functie voor het beheersen van beveiligingsincidenten
• Communiceer kritieke beveiligingsincidenten naar de Atlassian Leadership Group


Volgens dit beleid hanteert Atlassian een plan voor Beveiligingsincidentrespons. Voor meer informatie over ons proces voor Beveiligingsincidentrespons, zie: https://www.atlassian.com/trust/security/security-incident-management

Belangrijke systeemlogs worden vanaf elk systeem doorgestuurd naar een gecentraliseerd logplatform, waar logs alleen gelezen kunnen worden. Het Beveiligingsteam van Atlassian maakt waarschuwingen aan op ons platform voor beveiligingsanalyses (Splunk) en controleert op tekenen van aantasting. Onze SRE-teams gebruiken het platform om te controleren op problemen met beschikbaarheid of prestaties. Logs worden 30 dagen bewaard in hot back-up en 365 dagen in de cold back-up.

Ga voor meer informatie over ons detectieprogramma naar https://www.atlassian.com/trust/security/detections-program

6.07.01. (b)

Is dit proces geoefend om te controleren of de procedures voor de behandeling van incidenten effectief zijn? Zorgt de provider er tijdens de oefening ook voor dat iedereen binnen de ondersteuningsorganisatie van de cloudprovider op de hoogte is van het proces en van hun rol bij de afhandeling van incidenten (zowel tijdens het incident als na de analyse)?

Voor onze Atlassian Cloud-services worden plannen voor Bedrijfscontinuïteit en Disaster Recovery minstens elk kwartaal getest. De beschikbaarheid in meerdere regio's wordt in realtime gemonitord. Elke week worden er geautomatiseerde regio-failover-tests uitgevoerd in een preproductieomgeving. Tijdens de productie worden dagelijks geautomatiseerde tests voor het herstellen van configuratiegegevens uitgevoerd. Bij alle services van Atlassian wordt elk kwartaal het herstelvermogen getest van de Availability Zone in de preproductieomgeving. Voor meer informatie over ons programma voor bedrijfscontinuïteit, zie: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

Onze Disaster Recovery-plannen worden getest en gevalideerd door onze externe controleurs als onderdeel van ons nalevingsprogramma. Zie voor meer informatie: https://www.atlassian.com/trust/compliance/resources

We hebben ons Beveiligingsincidentresponsplan uitgevoerd door middel van live incidentactiviteiten. We volgen een aanpak die gericht is op continue verbetering om onze responsmogelijkheden te optimaliseren.

Nadat een ernstig incident met ernstniveau 1 of 2 is opgelost, wordt het oorspronkelijke ticket voor het incident gesloten en wordt een proces voor de beoordeling van het incident (PIR) gestart. Voor zeer ernstige incidenten voert het beveiligingsteam een analyse van de hoofdoorzaak uit en stelt het mogelijke verbeteringen voor voor het systeem en/of de behandeling van het probleem.

6.07.01. (c)

Hoe zijn de detectiemogelijkheden gestructureerd?

• Hoe kan de cloudklant afwijkingen en beveiligingsgebeurtenissen melden aan de provider?
• Welke faciliteiten biedt de provider voor door de klant geselecteerde externe RTSM-services om in hun systemen in te grijpen (indien van toepassing) of om incidentresponsmogelijkheden te coördineren met de cloudprovider?
• Is er een service voor realtime monitoring van beveiliging (RTSM)? Is de service uitbesteed? Welke parameters en services worden gemonitord?
• Verstrek je (op aanvraag) een periodiek rapport over veiligheidsincidenten (bijv. volgens de ITIL-definitie)?
• Hoelang worden de beveiligingslogs bewaard? Worden die logs veilig bewaard? Wie heeft toegang tot de logs?
• Kan de klant een HIPS/HIDS bouwen in images van de virtuele machine? Is het mogelijk om de informatie die wordt verzameld door de inbraakdetectie- en preventiesystemen van de klant te integreren in de RTSM-service van de cloudprovider of die van een externe partij?

Ons Atlassian Cloud Platform heeft heel weinig oppervlakte dat door de firewalls wordt blootgesteld. We herzien de firewall-regels periodiek. We hebben IDS geïmplementeerd op onze kantoorlocaties en in onze cloudhostingomgeving. Voor het Atlassian Cloud Platform kan het doorsturen van logs geïntegreerd worden met een platform voor beveiligingsanalyse. Op containerniveau van het Cloud Platform wordt de bestandsintegriteit gehandhaafd omdat de installaties niet kunnen worden aangepast. Atlassian Network Engineering maakt gebruik van IPS-technologieën die zijn ingebouwd in onze firewalls. Ook hebben we IDS-technologieën geïmplementeerd in onze kantoor- en cloudomgevingen. DDoS-mogelijkheden worden geleverd door onze internetprovider. Ga voor meer informatie over ons detectieprogramma naar https://www.atlassian.com/trust/security/detections-program Sleutelsysteemlogs worden vanaf elk systeem doorgestuurd naar een gecentraliseerd logplatform, waar logs alleen gelezen kunnen worden. Het Beveiligingsteam van Atlassian maakt waarschuwingen aan op ons platform voor beveiligingsanalyses (Splunk) en controleert op tekenen van schade. Onze SRE-teams gebruiken het platform om te controleren op problemen met beschikbaarheid of prestaties. Logs worden 30 dagen bewaard in de hot back-up en 365 dagen in de cold back-up. Atlassian beperkt de mogelijkheid om auditlogs te bekijken en te lezen tot bevoegd personeel op ons gecentraliseerde logplatform. Atlassian onderhoudt externe rapportagekanalen die ons kunnen informeren over kwetsbaarheden of incidenten. Voorbeelden daarvan zijn ons Bug Bounty-programma, onze supportportal voor klanten en vaste e-mailinboxen en telefoonnummers voor beveiliging. Atlassian moedigt klanten aan om niet-geautoriseerde toegang of kwaadaardig gedrag te melden. Ga voor meer informatie naar https://www.atlassian.com/trust/security/security-incident-management en https://www.atlassian.com/trust/security/security-incident-responsibilities.

6.07.01. (d)

Hoe worden de ernstniveaus gedefinieerd?

Atlassian gebruikt het Common Vulnerability Scoring System (CVSS) als een methode om het veiligheidsrisico te beoordelen en prioriteiten te stellen voor elke ontdekte kwetsbaarheid. De gebruikte beveiligingsniveaus zijn gebaseerd op de zelf berekende CVSS-score van Atlassian, waaronder:

• Kritiek;
• Hoog;
• Gemiddeld en
• Laag.


Ga voor meer informatie, waaronder welke scorebereiken de ernst bepalen, naar: https://www.atlassian.com/trust/security/security-severity-levels.

6.07.01. (e)

Hoe worden escalatieprocedures gedefinieerd? Wanneer (indien ooit) is de cloudklant erbij betrokken?

We hebben een gedocumenteerd beleid en plan voor Beveiligingsincidentrespons. De belangrijkste principes hiervan omvatten het volgende:

• Anticipeer op beveiligingsincidenten en bereid je voor op incidentrespons
• Werk aan het inperken, uitroeien en herstellen van incidenten
• Investeer in onze mensen, processen en technologieën om ervoor te zorgen dat we de mogelijkheid hebben om een beveiligingsincident te detecteren en te analyseren wanneer het zich voordoet
• Geef de bescherming van persoonsgegevens en klantgegevens de hoogste prioriteit tijdens beveiligingsincidenten
• Oefen regelmatig het responsproces voor beveiligingsincidenten
• Leer van en verbeter de functie voor het beheersen van beveiligingsincidenten
• Communiceer kritieke beveiligingsincidenten naar de Atlassian Leadership Group


Volgens dit beleid hanteert Atlassian een plan voor Beveiligingsincidentrespons. Voor meer informatie over ons proces voor Beveiligingsincidentrespons, zie: https://www.atlassian.com/trust/security/security-incident-management

Atlassian begrijpt hoe belangrijk het is dat je onmiddellijk op de hoogte wordt gebracht van een datalek. Daarom heeft Atlassian een uitgebreid multifunctioneel team en proces samengesteld om beveiligingsincidenten af te handelen, zoals beschreven op: https://www.atlassian.com/trust/security/security-incident-management

Atlassian heeft een goede staat van dienst op het gebied van tijdige en proactieve meldingen van incidenten en samenwerking met onze klanten aan de nodige maatregelen.

Omdat het van cruciaal belang is dat de teams van Atlassian voor incidentrespons op beveiligingsicidenten zich onmiddellijk concentreren op het sorteren en beperken van een incident naarmate het zich ontwikkelt, kunnen we niet instemmen met een tijdlijn van 72 uur. In plaats daarvan geven we klanten een melding 'zonder onnodige vertraging', wat de wettelijke vereisten naleeft op grond van de AVG voor gegevensverwerkers. Dit voldoet aan de wettelijke behoeften van het grootste deel van onze klanten.

Incidenten kunnen variëren van eenvoudig tot ongelooflijk complex, dus hoewel we kunnen bieden wat volgens de wet verplicht is, kunnen we niet instemmen met een tijdlijn die voor iedereen geschikt is.

6.07.01. (f)

Hoe worden incidenten gedocumenteerd en hoe wordt het bewijs verzameld?

Jira-tickets worden aangemaakt voor opsporings- en hersteldoeleinden, en vervaldatums worden toegewezen volgens onze SLO op basis van zowel de ernst als de oorzaak van de kwetsbaarheid. We hebben een lopend proces om tickets voor geïdentificeerde kwetsbaarheden uit te vaardigen aan systeemeigenaren, en ons beveiligingsmanagementteam beoordeelt alle gerapporteerde kwetsbaarheden en zorgt ervoor dat er actie wordt ondernomen tegen deze kwetsbaarheden.

Nadat een ernstig incident met ernstniveau 1 of 2 is opgelost, wordt het oorspronkelijke ticket voor het incident gesloten en wordt een proces voor de beoordeling van het incident (PIR) gestart. Voor zeer ernstige incidenten voert het beveiligingsteam een analyse van de hoofdoorzaak uit en stelt het mogelijke verbeteringen voor voor het systeem en/of de behandeling van het probleem.

6.07.01. (g)

Welke andere controles zijn er, naast authenticatie, boekhouding en audit, om kwaadaardige activiteiten door insiders te voorkomen (of de impact ervan tot een minimum te beperken)?

Atlassian heeft IDS geïmplementeerd op onze kantoorlocaties en in onze cloudhostingomgeving. Het doorsturen van logs is geïntegreerd met een platform voor beveiligingsanalyses voor het Atlassian Cloud Platform. Sleutelsysteemlogs worden vanaf elk systeem doorgestuurd naar een gecentraliseerd logplatform, waar logs alleen gelezen kunnen worden. Het Beveiligingsteam van Atlassian maakt waarschuwingen aan op ons platform voor beveiligingsanalyses (Splunk) en controleert op tekenen van schade. Ga voor meer informatie over ons detectieprogramma naar https://www.atlassian.com/trust/security/detections-program

6.07.01. (h)

Verzamelt de provider statistieken en indicatoren voor incidenten (bijv. het aantal gedetecteerde of gemelde incidenten per maand, het aantal incidenten veroorzaakt door de onderaannemers van de cloudprovider en het totale aantal van dergelijke incidenten, gemiddelde tijd om te reageren en op te lossen, enz.)?

• Welke van deze gegevens maakt de provider openbaar (NB: niet alle gegevens over het melden van incidenten kunnen openbaar worden gemaakt omdat dit de vertrouwelijkheid van de klant in gevaar kan brengen en kritieke informatie met betrekking tot de veiligheid kan onthullen)?

Op dit moment maken we onze interne statistieken niet openbaar, maar we delen wel acties na een incident voor operationele incidenten van Ernstniveau 0 of Ernstniveau 1 op onze Statuspage, zie: https://status.atlassian.com/.

6.07.01. (j)

Hoe vaak test de provider disaster recovery- en bedrijfscontinuïteitsplannen?

Voor onze Atlassian Cloud-services worden plannen voor Bedrijfscontinuïteit en Disaster Recovery minstens elk kwartaal getest. De beschikbaarheid in meerdere regio's wordt in realtime gemonitord. Elke week worden er geautomatiseerde regio-failover-tests uitgevoerd in een preproductieomgeving. Tijdens de productie worden dagelijks geautomatiseerde tests voor het herstellen van configuratiegegevens uitgevoerd. Bij alle services van Atlassian wordt elk kwartaal het herstelvermogen getest van de Availability Zone in de preproductieomgeving. Voor meer informatie over ons programma voor bedrijfscontinuïteit, zie: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

Onze Disaster Recovery-plannen worden getest en gevalideerd door onze externe controleurs als onderdeel van ons nalevingsprogramma. Zie voor meer informatie: https://www.atlassian.com/trust/compliance/resources

6.07.01. (k)

Verzamelt de provider gegevens over de mate van tevredenheid met SLA's?

We controleren alle Cloud-installaties op prestaties en beschikbaarheid, maar we bieden momenteel geen formele SLA voor de beschikbaarheid van applicaties. Ons supportteam biedt een SLA voor de eerste reactietijd, en hoewel we geen officiële SLA voor het oplossen hebben, is ons interne doel om alle toegewezen gevallen binnen 48 uur op te lossen. Atlassian toont hier de statistieken over de status van ons laatste Cloud-systeem: https://status.atlassian.com.

Als je ervoor kiest om gebruik te maken van ons Premium- of Enterprise-aanbod, zo ja, dan bieden we SLA-garanties.

6.07.01. (l)

Voert de provider tests uit op de helpdesk? Bijvoorbeeld:

• Impersonatietests (is de persoon aan de telefoon die vraagt om een nieuw wachtwoord werkelijk wie deze beweert te zijn?) of zogenaamde 'social engineering'-aanvallen.

Atlassian biedt informatiebeveiligingstrainingen als onderdeel van een onboardingtraining ('dag 1') voor nieuwe medewerkers en doorlopend voor al het personeel.

Naast deze algemene informatiebeveiligingstraining worden onze ontwikkelaars gerichter getraind op het gebied van veilig coderen. Deze wordt ondersteund door ons programma voor geïntegreerde beveiligingsingenieurs.

We geven ook doorlopende actuele trainingen over malware, phishing en andere beveiligingsproblemen. https://www.atlassian.com/trust/security/security-practices#security-awareness-training

We houden formele records bij over de voltooiing van de interne opleiding van personeel. Werknemers moeten de gedragscode jaarlijks erkennen en opnieuw bevestigen. Dit beleid is bedoeld voor alle werknemers. De vereisten op het gebied van veiligheidsbewustzijn, vertrouwelijkheid en privacy worden gepresenteerd in hun dagelijkse trainingen en zijn beschikbaar voor alle werknemers in Confluence.

6.07.01. (m)

Voert de provider penetratietests uit? Hoe vaak? Wat wordt er eigenlijk getest tijdens de penetratietest. Testen ze bijvoorbeeld de veiligheidsisolatie van elke image om er zeker van te zijn dat het niet mogelijk is om uit een image te breken naar een andere en zo ook toegang te krijgen tot de hostinfrastructuur? Tijdens de tests moet ook worden nagegaan of het mogelijk is om via de virtuele image toegang te krijgen tot de beheer- en ondersteuningssystemen van de cloudprovider (bijvoorbeeld de systemen voor registratie en toegangscontrole voor beheerders).

We hebben een intern Red Team dat doorlopend penetratietests uitvoert voor al onze infrastructuur, cloudservices en mensen.

We schakelen externe adviesbureaus in om jaarlijkse penetratietests uit te voeren op extern gerichte applicaties. We vullen deze tests ook aan met kleinere, doorlopende beveiligingstests, uitgevoerd door ons interne beveiligingstestteam. De beoordelingsbrieven voor deze penetratietests zijn hier te vinden, samen met meer informatie over ons testproces en onze aanpak van externe veiligheidstests, zie: https://www.atlassian.com/trust/security/security-testing.

6.07.01. (n)

Voert de provider kwetsbaarheidstests uit? Hoe vaak?

Het Beveiligingsteam van Atlassian voert doorlopend scans voor netwerkkwetsbaarheden uit van zowel de interne als externe infrastructuur met behulp van een in de branche erkende kwetsbaarheidsscanner. Ga voor meer informatie over ons programma voor kwetsbaarheidsbeheer naar: https://www.atlassian.com/trust/security/vulnerability-management.

6.07.01. (o)

Wat is het proces om kwetsbaarheden te verhelpen (hotfixes, herconfiguratie, upgrade naar latere softwareversies, enz.)?

Jira-tickets worden aangemaakt voor opsporings- en hersteldoeleinden, en vervaldatums worden toegewezen volgens onze SLO op basis van zowel de ernst als de oorzaak van de kwetsbaarheid. We hebben een lopend proces om tickets voor geïdentificeerde kwetsbaarheden uit te vaardigen aan systeemeigenaren, en ons beveiligingsmanagementteam beoordeelt alle gerapporteerde kwetsbaarheden en zorgt ervoor dat er actie wordt ondernomen tegen deze kwetsbaarheden.

Details over ons programma voor kwetsbaarheidsbeheer zijn te vinden op: https://www.atlassian.com/trust/security/vulnerability-management.

6.08.

Net als bij de personeelsbeveiliging ontstaan veel van de mogelijke problemen omdat de IT-infrastructuur onder controle staat van een externe partij. Zoals bij traditionele uitbesteding kan het effect van een inbreuk op de fysieke beveiliging gevolgen hebben voor meerdere klanten (organisaties).

6.08. (a)

Welke verzekering geef je de klant met betrekking tot de fysieke beveiliging van de locatie? Geef voorbeelden en eventuele normen waaraan wordt voldaan, bijvoorbeeld: sectie 9 van ISO 27001/2.

Fysieke beveiligingscontroles in onze kantoren worden geleid door ons beleid voor fysieke beveiliging en omgevingsbeveiliging, dat ervoor zorgt dat overal op locatie in onze omgevingen en in de cloud betrouwbare fysieke beveiliging geïmplementeerd is.

De datacenters waar wij mee werken voldoen minimaal aan SOC-2. Deze certificeringen hebben betrekking op verscheidene beveiligingsmaatregelen, waaronder fysieke beveiliging en bescherming en omgevingsbeveiliging en -bescherming. Toegang tot de datacenters wordt beperkt tot geautoriseerd personeel en gecontroleerd met biometrische identiteitscontroles. Fysieke beveiligingsmaatregelen omvatten bewakers op locatie, videobewaking, sluizen en aanvullende maatregelen voor inbraakbeveiliging.

6.08. (a) (i)

Wie heeft, behalve geautoriseerd IT-personeel, onbegeleide (fysieke) toegang tot de IT-infrastructuur?

• Bijvoorbeeld schoonmakers, managers, personeel voor de 'fysieke beveiliging', aannemers, consultants, verkopers, enz.

Onze Atlassian-kantoren laten zich leiden door ons interne beleid inzake fysieke beveiliging en omgevingsbeveiliging, waaronder het monitoren van fysieke in- en uitgangen. We hebben uittreksels van ons gehele interne technologiebeleid en veiligheidsbeleid gepubliceerd op: https://www.atlassian.com/trust/security/ismp-policies

Kantoren van Atlassian hebben toegangscontroles, waaronder badgelezers en cameratoezicht. Ook is er de mogelijkheid om de toegang te beperken tot specifieke tijden/dagen als dat nodig is. Logs van toegang tot kantoorgebouwen worden bijgehouden door het gebouwbeheer en zijn beschikbaar voor Workplace Experience voor onderzoeksdoeleinden.

De Data Centers van onze partners beschikken over meerdere nalevingscertificeringen. Deze certificeringen hebben betrekking op fysieke beveiliging, systeembeschikbaarheid, netwerk- en IP-backbone-toegang, klantprovisioning en probleembeheer. Toegang tot de Data Centers wordt beperkt tot bevoegd personeel en gecontroleerd met biometrische identiteitscontroles. Fysieke beveiligingsmaatregelen omvatten: on-premise-bewakers, videobewaking met gesloten circuit, toegangssluizen en aanvullende maatregelen tegen inbraak. Informatie over de fysieke bescherming van AWS is te vinden op: http://aws.amazon.com/compliance/

6.08. (a) (ii)

Hoe vaak worden de toegangsrechten herzien?

• Hoe snel kunnen toegangsrechten worden ingetrokken?

Atlassian evalueert de prestaties en effectiviteit van de ISMS aan de hand van geschikte statistieken. We monitoren de prestaties van het Atlassian Trust Management System (ATMS) en de relevante controles via interne en externe audits. Het Atlassian Compliance Team beheert zowel onze planning voor de Internal / Internal Audits als onze planning voor External Audits (die intern worden gedocumenteerd op onze pagina met roadmaps voor audits). Interne audits zijn gericht op gebieden met een hoog risico in Atlassian en vinden regelmatig plaats volgens vooraf bepaalde planningen en volgens het Enterprise Audit Schedule dat is overeengekomen tussen het Risk and Compliance Team en het Internal Audit Team. Op dit moment maken we onze interne statistieken niet openbaar. Het ATMS wordt jaarlijks beoordeeld door onafhankelijke externe partijen en ook na belangrijke veranderingen. Atlassian heeft de SOC 2-, ISO27001- en ISO27018-certificeringen behaald voor elk hun grote cloudservices. Atlassian houdt ook toezicht op elk van de pijlers van het ATMS door middel van periodieke operationele beoordelingsvergaderingen, inclusief specifieke statistieken voor elke pijler. Dit omvat wekelijkse nalevingsbeoordelingen van het ATMS en andere vergaderingen die intern worden gedocumenteerd op het ATMS: de pagina voor nalevingsbeoordelingen en de pagina met notulen over het ATMS. Ga voor meer informatie naar https://www.atlassian.com/trust/compliance.

We hebben een formeel programma voor beveiligingsbeheer en we herzien ons Information Security Management Program (ISMP) op jaarbasis. Zie https://www.atlassian.com/trust/security/security-management-program voor meer informatie over ons programma voor beveiligingsbeheer.

6.08. (a) (iii)

Beoordeel je regelmatig veiligheidsrisico's en evalueer je perimeters?

• Hoe vaak?

Atlassian evalueert de prestaties en effectiviteit van de ISMS aan de hand van geschikte statistieken. We monitoren de prestaties van het Atlassian Trust Management System (ATMS) en de relevante controles via interne en externe audits. Het Atlassian Compliance Team beheert zowel onze planning voor de Internal / Internal Audits als onze planning voor External Audits (die intern worden gedocumenteerd op onze pagina met roadmaps voor audits). Interne audits zijn gericht op gebieden met een hoog risico in Atlassian en vinden regelmatig plaats volgens vooraf bepaalde planningen en volgens het Enterprise Audit Schedule dat is overeengekomen tussen het Risk and Compliance Team en het Internal Audit Team. Op dit moment maken we onze interne statistieken niet openbaar. Het ATMS wordt jaarlijks beoordeeld door onafhankelijke externe partijen en ook na belangrijke veranderingen. Atlassian heeft de SOC 2-, ISO27001- en ISO27018-certificeringen behaald voor elk hun grote cloudservices. Atlassian houdt ook toezicht op elk van de pijlers van het ATMS door middel van periodieke operationele beoordelingsvergaderingen, inclusief specifieke statistieken voor elke pijler. Dit omvat wekelijkse nalevingsbeoordelingen van het ATMS en andere vergaderingen die intern worden gedocumenteerd op het ATMS: de pagina voor nalevingsbeoordelingen en de pagina met notulen over het ATMS. Ga voor meer informatie naar https://www.atlassian.com/trust/compliance.

We hebben een formeel programma voor beveiligingsbeheer en we herzien ons Information Security Management Program (ISMP) op jaarbasis. Zie https://www.atlassian.com/trust/security/security-management-program voor meer informatie over ons programma voor beveiligingsbeheer.

6.08. (a) (iv)

Voer je regelmatig risicobeoordelingen uit, waaronder bijvoorbeeld voor aangrenzende gebouwen?

Atlassian evalueert de prestaties en effectiviteit van de ISMS aan de hand van geschikte statistieken. We monitoren de prestaties van het Atlassian Trust Management System (ATMS) en de relevante controles via interne en externe audits. Het Atlassian Compliance Team beheert zowel onze planning voor de Internal / Internal Audits als onze planning voor External Audits (die intern worden gedocumenteerd op onze pagina met roadmaps voor audits). Interne audits zijn gericht op gebieden met een hoog risico in Atlassian en vinden regelmatig plaats volgens vooraf bepaalde planningen en volgens het Enterprise Audit Schedule dat is overeengekomen tussen het Risk and Compliance Team en het Internal Audit Team. Op dit moment maken we onze interne statistieken niet openbaar. Het ATMS wordt jaarlijks beoordeeld door onafhankelijke externe partijen en ook na belangrijke veranderingen. Atlassian heeft de SOC 2-, ISO27001- en ISO27018-certificeringen behaald voor elk hun grote cloudservices. Atlassian houdt ook toezicht op elk van de pijlers van het ATMS door middel van periodieke operationele beoordelingsvergaderingen, inclusief specifieke statistieken voor elke pijler. Dit omvat wekelijkse nalevingsbeoordelingen van het ATMS en andere vergaderingen die intern worden gedocumenteerd op het ATMS: de pagina voor nalevingsbeoordelingen en de pagina met notulen over het ATMS. Ga voor meer informatie naar https://www.atlassian.com/trust/compliance.

We hebben een formeel programma voor beveiligingsbeheer en we herzien ons Information Security Management Program (ISMP) op jaarbasis. Zie https://www.atlassian.com/trust/security/security-management-program voor meer informatie over ons programma voor beveiligingsbeheer.

6.08. (a) (v)

Controleer je of monitor je personeel (waaronder externe partijen) dat toegang heeft tot beveiligde ruimtes?

Onze Atlassian-kantoren laten zich leiden door ons interne beleid inzake fysieke beveiliging en omgevingsbeveiliging, waaronder het monitoren van fysieke in- en uitgangen. We hebben uittreksels van ons gehele interne technologiebeleid en veiligheidsbeleid gepubliceerd op: https://www.atlassian.com/trust/security/ismp-policies

Kantoren van Atlassian hebben toegangscontroles, waaronder badgelezers en cameratoezicht. Ook is er de mogelijkheid om de toegang te beperken tot specifieke tijden/dagen als dat nodig is. Logs van toegang tot kantoorgebouwen worden bijgehouden door het gebouwbeheer en zijn beschikbaar voor Workplace Experience voor onderzoeksdoeleinden.

De Data Centers van onze partners beschikken over meerdere nalevingscertificeringen. Deze certificeringen hebben betrekking op fysieke beveiliging, systeembeschikbaarheid, netwerk- en IP-backbone-toegang, klantprovisioning en probleembeheer. Toegang tot de Data Centers wordt beperkt tot bevoegd personeel en gecontroleerd met biometrische identiteitscontroles. Fysieke beveiligingsmaatregelen omvatten: on-premise-bewakers, videobewaking met gesloten circuit, toegangssluizen en aanvullende maatregelen tegen inbraak. Informatie over de fysieke bescherming van AWS is te vinden op: http://aws.amazon.com/compliance/

6.08. (a) (vi)

Welk beleid of welke procedures heb je voor het laden, lossen en installeren van apparatuur?

In de kantoorfaciliteiten van Atlassian zijn de laadperrons afgezonderd van de werkplekken en worden ze te allen tijde bewaakt via cameratoezicht en door het personeel van het gebouw. Onze hostingpartners voor Data Centers beheren de fysieke beveiliging en we vertrouwen op hun nalevingscertificaten om te valideren dat de controles effectief zijn.

6.08. (a) (vii)

Worden leveringen vóór de installatie onderzocht op risico's?

In de kantoorfaciliteiten van Atlassian zijn de laadperrons afgezonderd van de werkplekken en worden ze te allen tijde bewaakt via cameratoezicht en door het personeel van het gebouw. Onze hostingpartners voor Data Centers beheren de fysieke beveiliging en we vertrouwen op hun nalevingscertificaten om te valideren dat de controles effectief zijn.

6.08. (a) (viii)

Is er een actuele fysieke inventaris van items in het Data Center?

Een uittreksel van ons beleid voor assetbeheer is beschikbaar op https://www.atlassian.com/trust/security/ismp-policies. Atlassian houdt een inventaris bij van alle productie-assets en van de eigenaren van assets. Al onze systemen bevinden zich in Data Centers op basis van AWS. Deze systemen worden niet op hardwareniveau bijgehouden vanwege de aard van de service.

Alle microservices worden bijgehouden in een aangepaste Servicedatabase, die wordt bijgewerkt wanneer een Service wordt geïmplementeerd. Workplace Technology (WPT) van Atlassian gebruikt hun eigen Jira Software om een assetinventaris bij te houden van alle eindpunten voor trackingdoeleinden.

Alle microservices zijn onderverdeeld in niveaus. Aan elk niveau zijn de verwachtingen inzake uptime, beschikbaarheid, RTO en RPO gekoppeld. Zie https://www.atlassian.com/trust/security/data-management voor meer informatie.

6.08. (a) (ix)

Lopen netwerkkabels door ruimtes met openbare toegang?

• Gebruik je gewapende bekabeling of leidingen?

Onze Atlassian-kantoren laten zich leiden door ons interne beleid inzake fysieke beveiliging en omgevingsbeveiliging, waaronder het monitoren van fysieke in- en uitgangen. We hebben uittreksels van ons gehele interne technologiebeleid en veiligheidsbeleid gepubliceerd op: https://www.atlassian.com/trust/security/ismp-policies

Kantoren van Atlassian hebben toegangscontroles, waaronder badgelezers en cameratoezicht. Ook is er de mogelijkheid om de toegang te beperken tot specifieke tijden/dagen als dat nodig is. Logs van toegang tot kantoorgebouwen worden bijgehouden door het gebouwbeheer en zijn beschikbaar voor Workplace Experience voor onderzoeksdoeleinden.

6.08. (a) (x)

Doe je regelmatig onderzoek naar gebouwen om te zoeken naar ongeautoriseerde apparatuur?

Een uittreksel van ons beleid voor assetbeheer is beschikbaar op https://www.atlassian.com/trust/security/ismp-policies. Atlassian houdt een inventaris bij van alle productie-assets en van de eigenaren van assets. Al onze systemen bevinden zich in datacenters op basis van AWS. Deze systemen worden niet op hardwareniveau bijgehouden vanwege de aard van de service.

Alle microservices worden bijgehouden in een aangepaste Servicedatabase, die wordt bijgewerkt wanneer een Service wordt geïmplementeerd. Workplace Technology (WPT) van Atlassian gebruikt hun eigen Jira Software om een assetinventaris bij te houden van alle eindpunten voor trackingdoeleinden.

6.08. (a) (xi)

Is er apparatuur op een andere locatie?

• Hoe wordt dit beschermd?

Een uittreksel van ons beleid voor assetbeheer is beschikbaar op https://www.atlassian.com/trust/security/ismp-policies. Atlassian houdt een inventaris bij van alle productie-assets en van de eigenaren van assets. Al onze systemen bevinden zich in datacenters op basis van AWS. Deze systemen worden niet op hardwareniveau bijgehouden vanwege de aard van de service.

Alle microservices worden bijgehouden in een aangepaste Servicedatabase, die wordt bijgewerkt wanneer een Service wordt geïmplementeerd. Workplace Technology (WPT) van Atlassian gebruikt hun eigen Jira Software om een assetinventaris bij te houden van alle eindpunten voor trackingdoeleinden.

6.08. (a) (xii)

Gebruikt je personeel draagbare apparatuur (bijv. Laptops, smartphones) die toegang kunnen geven tot het Data Center?

• Hoe worden deze beschermd?

De Data Centers van onze partners beschikken over meerdere nalevingscertificeringen. Deze certificeringen hebben betrekking op fysieke beveiliging, systeembeschikbaarheid, netwerk- en IP-backbone-toegang, klantprovisioning en probleembeheer. Toegang tot de Data Centers wordt beperkt tot bevoegd personeel en gecontroleerd met biometrische identiteitscontroles. Fysieke beveiligingsmaatregelen omvatten: on-premise-bewakers, videobewaking met gesloten circuit, toegangssluizen en aanvullende maatregelen tegen inbraak. Informatie over de fysieke bescherming van AWS is te vinden op: http://aws.amazon.com/compliance/

Geautoriseerde en opgeleide leden van Atlassian Engineering-teams die een achtergrondonderzoek hebben ondergaan, authenticeren zich bij de VPN met unieke sterke wachtwoorden en 2FA op basis van TOTP. Zij hebben dan alleen toegang tot de productieomgeving via ssh-terminalverbindingen met behulp van persoonlijke RSA-certificaten die met een wachtwoordzin zijn beveiligd. Op alle productieservers is een IDS-systeem geïnstalleerd, dat voor monitoring en waarschuwing in realtime zorgt bij eventuele veranderingen in de bestanden of configuratie van het productiesysteem en abnormale beveiligingsgebeurtenissen. Voor de bevoegde en getrainde leden van het operationele team die toegang hebben tot het productiesysteem: alle werkstations met Windows of OS X die worden gebruikt voor toegang tot de ssh-terminal tot de productieomgeving, moeten zijn voorzien van actuele en actieve antivirussoftware. Klantgegevens worden niet gerepliceerd naar werkstations of mobiele apparaten van werknemers.

6.08. (a) (xiii)

Welke maatregelen zijn er genomen om de toegangspassen te controleren?

Onze Atlassian-kantoren laten zich leiden door ons interne beleid inzake fysieke beveiliging en omgevingsbeveiliging, waaronder het monitoren van fysieke in- en uitgangen. We hebben uittreksels van ons gehele interne technologiebeleid en veiligheidsbeleid gepubliceerd op: https://www.atlassian.com/trust/security/ismp-policies

Kantoren van Atlassian hebben toegangscontroles, waaronder badgelezers en cameratoezicht. Ook is er de mogelijkheid om de toegang te beperken tot specifieke tijden/dagen als dat nodig is. Logs van toegang tot kantoorgebouwen worden bijgehouden door het gebouwbeheer en zijn beschikbaar voor Workplace Experience voor onderzoeksdoeleinden.

6.08. (a) (xiv)

Welke processen of procedures zijn er om oude media of systemen te vernietigen wanneer dat nodig is?

• Overschrijving van gegevens?
• Fysieke vernietiging?

Workplace Technology zorgt voor dit proces. Apparatuur wordt op de juiste manier ontsmet en gedemagnetiseerd. Atlassian beheert geen fysieke media die hun cloudproducten en -services ondersteunen.

6.08. (a) (xv)

Welke autorisatieprocedures zijn er voor de verplaatsing van apparatuur van de ene locatie naar de andere?

• Hoe identificeer je personeel (of contractanten) die hiervoor bevoegd zijn?

De hostingpartners voor Data Centers (AWS) van Atlassian beheren de fysieke beveiliging, en we vertrouwen op hun SOC2 om te valideren dat de controles effectief zijn.

Atlassian Cloud-producten verplaatsen klantgegevens niet fysiek. Harde schijven met klantgegevens worden vernietigd of ontsmet voordat ze onze beveiligde AWS-datacenters verlaten. Voor systemen die worden gehost in AWS, kunnen gegevens in een overtolligheidsscenario tussen regio's worden verplaatst, maar blijven ze binnen de AWS. Zie https://www.atlassian.com/trust/reliability/infrastructure voor meer informatie over onze AWS-regio's.

6.08. (a) (xvi)

Hoe vaak worden er audits van apparatuur uitgevoerd om te controleren of er ongeautoriseerde apparatuur is verwijderd?

De hostingpartners voor Data Centers (AWS) van Atlassian beheren de fysieke beveiliging, en we vertrouwen op hun SOC2 om te valideren dat de controles effectief zijn.

Atlassian Cloud-producten verplaatsen klantgegevens niet fysiek. Harde schijven met klantgegevens worden vernietigd of ontsmet voordat ze onze beveiligde AWS-datacenters verlaten. Voor systemen die worden gehost in AWS, kunnen gegevens in een overtolligheidsscenario tussen regio's worden verplaatst, maar blijven ze binnen de AWS. Zie https://www.atlassian.com/trust/reliability/infrastructure voor meer informatie over onze AWS-regio's.

6.08. (a) (xvii)

Hoe vaak worden er controles uitgevoerd om ervoor te zorgen dat de omgeving voldoet aan de toepasselijke wet- en regelgeving?

Ons Atlassian Legal Team en onze nalevingsteams houden toezicht op onze wettelijke verplichtingen. Zie https://www.atlassian.com/legal/ voor ons juridische programma. Meer informatie over ons nalevingsprogramma is te vinden op: https://www.atlassian.com/trust/compliance.

6.09. (a)

Welke procedures of beleidsmaatregelen zijn er om ervoor te zorgen dat problemen in de omgeving niet leiden tot een onderbreking van de dienstverlening?

Onze Atlassian-kantoren laten zich leiden door ons interne beleid inzake fysieke beveiliging en omgevingsbeveiliging, waaronder het monitoren van fysieke in- en uitgangen.

De Data Centers van onze partners beschikken over meerdere nalevingscertificeringen. Deze certificeringen hebben betrekking op fysieke beveiliging, systeembeschikbaarheid, netwerk- en IP-backbone-toegang, klantprovisioning en probleembeheer. Toegang tot de Data Centers wordt beperkt tot bevoegd personeel en gecontroleerd met biometrische identiteitscontroles. Fysieke beveiligingsmaatregelen omvatten: on-premise-bewakers, videobewaking met gesloten circuit, toegangssluizen en aanvullende maatregelen tegen inbraak. Informatie over de fysieke bescherming van AWS is te vinden op: http://aws.amazon.com/compliance/

Er is een beleid en een plan voor bedrijfscontinuïteit en disaster recovery van kracht; deze worden jaarlijks herzien door de stuurgroep voor Bedrijfscontinuïteit/Disaster recovery. Eigenaren van bedrijfskritieke systemen en processen en service-eigenaren moeten zorgen voor goede bedrijfscontinuïteit en/of disaster recovery in overeenstemming met de tolerantie voor verstoring in geval van een ramp. De BCDR-plannen worden elk kwartaal getest en alle geïdentificeerde issues worden opgelost. Zie https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management en https://www.atlassian.com/trust/security/data-management voor meer informatie.

6.09. (b)

Welke methoden gebruik je om schade als gevolg van brand, overstroming, aardbeving, enz. te voorkomen?

• Welke aanvullende veiligheidsmaatregelen worden er genomen om de fysieke toegang te beschermen in geval van een ramp?
• Zowel op de primaire als op de secundaire locaties?

Atlassian vertrouwt op hun partners voor gegevenshosting om de beveiliging van hun datacenters en omgevingscontroles te valideren. Zie https://aws.amazon.com/compliance/programs voor AWS

6.09. (c)

Controleer je de temperatuur en luchtvochtigheid in het Data Center?

• Controles en overwegingen met betrekking tot airconditioning?

Atlassian vertrouwt op hun partners voor gegevenshosting om de beveiliging van hun datacenters en omgevingscontroles te valideren. Zie https://aws.amazon.com/compliance/programs voor AWS

6.09. (d)

Bescherm je je gebouwen tegen blikseminslagen?

• Ook elektrische leidingen en communicatielijnen?

Atlassian vertrouwt op hun partners voor gegevenshosting om de beveiliging van hun datacenters en omgevingscontroles te valideren. Zie https://aws.amazon.com/compliance/programs voor AWS

6.09. (e)

Heb je stand-alone-generatoren in het geval van een stroomstoring?

• Hoelang kunnen ze werken?
• Is er voldoende brandstof?
• Zijn er failover-generatoren?
• Hoe vaak controleer je UPS-apparatuur?
• Hoe vaak controleer je je generatoren?
• Heb je meerdere energieleveranciers?

Atlassian vertrouwt op hun partners voor gegevenshosting om de beveiliging van hun datacenters en omgevingscontroles te valideren. Zie https://aws.amazon.com/compliance/programs voor AWS

6.09. (f)

Zijn alle nutsvoorzieningen (elektriciteit, water, enz.) voldoende voor je omgeving?

• Hoe vaak wordt dit opnieuw geëvalueerd en getest?

Atlassian vertrouwt op hun partners voor gegevenshosting om de beveiliging van hun datacenters en omgevingscontroles te valideren. Zie https://aws.amazon.com/compliance/programs voor AWS

6.09. (g)

Is je airconditioning voldoende voor je omgeving?

• Hoe vaak wordt dit getest?

Atlassian vertrouwt op hun partners voor gegevenshosting om de beveiliging van hun datacenters en omgevingscontroles te valideren. Zie https://aws.amazon.com/compliance/programs voor AWS

6.09. (h)

Volg je de planningen voor onderhoudswerkzaamheden die zijn aanbevolen door de fabrikant?

Atlassian vertrouwt op hun partners voor gegevenshosting om de beveiliging van hun datacenters en omgevingscontroles te valideren. Zie https://aws.amazon.com/compliance/programs voor AWS

6.09. (i)

Laat je alleen geautoriseerd onderhouds- of reparatiemedewerkers toe op de locatie?

• Hoe controleer je hun identiteit?

De fysieke toegang tot kantoorfaciliteiten wordt beschermd door toegang met een elektronische badge, een receptie tijdens kantooruren met verplichte aanmelding voor bezoekers en cameratoezicht bij alle in- en uitgangen van het gebouw. De laadperrons worden te allen tijde bewaakt door cameratoezicht en personeel van het gebouw. Onze hostingpartners voor Data Centers beheren de fysieke beveiliging en we vertrouwen op hun nalevingscertificaten om te valideren dat de controles effectief zijn.

6.09. (j)

Als apparatuur wordt weggestuurd voor reparatie, worden de gegevens daar dan eerst uit verwijderd?

• Hoe doe je dat?

Workplace Technology zorgt voor dit proces. Apparatuur wordt op de juiste manier ontsmet en gedemagnetiseerd. Atlassian beheert geen fysieke media die hun cloudproducten en -services ondersteunen.

6.10.

Klanten en potentiële klanten van cloudproviderservices moeten rekening houden met hun respectievelijke nationale en supranationale verplichtingen met betrekking tot de naleving van regelgevingsframeworks. Ook dienen ze ervoor te zorgen dat dergelijke verplichtingen naar behoren worden nageleefd.

De belangrijkste juridische vragen die de klant aan de cloudprovider moet stellen, zijn:

6.10. (a)

In welk land is de cloudprovider gevestigd?

Atlassian heeft 12 kantoren in 8 landen, waaronder Sydney, Amsterdam, Ankara, Boston, Bangalore, San Francisco, Mountain View, Austin (Texas), NYC, Manilla, Gdansk en Japan. Ga voor meer informatie naar: https://www.atlassian.com/company/contact.

6.10. (b)

Bevindt de infrastructuur van de cloudprovider zich in hetzelfde land of in verschillende landen?

Wat Atlassian Cloud betreft, worden we momenteel gehost in overbodige AWS-beschikbaarheidszones. Raadpleeg https://www.atlassian.com/trust/reliability/infrastructure voor informatie over bepaalde regio's.

6.10. (c)

Gebruikt de cloudprovider andere bedrijven waarvan de infrastructuur zich buiten die van de cloudprovider bevindt?

Atlassian Cloud-producten en -gegevens worden gehost op de toonaangevende cloudprovider: Amazon Web Services (AWS). Onze producten draaien op een PaaS-omgeving (Platform as a Service) die is opgedeeld in twee primaire infrastructuursets. Deze primaire sets noemen we micros en niet-micros. Jira, Confluence, Statuspage, Access en Bitbucket draaien op het micros-platform, terwijl Opsgenie en Trello op het niet-micros-platform draaien.

6.10. (d)

Waar worden de gegevens fysiek opgeslagen?

Atlassian gebruikt Amazon Web Services (AWS) in de regio's VS-Oost, VS-West, Ierland, Frankfurt, Singapore en Sydney (Confluence en Jira).

Specifieke productgegevens:

• Trello: beschikbaar in AWS VS-Oost (Ohio).
• Jira Align: de fysieke locatie van klantgegevens kan opgevraagd worden via het verzoek om een supportticket. Raadpleeg: https://support.atlassian.com/jira-align/.
• Statuspage: beschikbaar in de regio's AWS VS-West (Oregon, Californië), VS-Oost (Ohio).
• Opsgenie: heeft AWS-accounts in zowel de VS als in Europa. De klant moet zich bij aanmelding aanmelden voor AWS VS (Oregon, Californië) of EU (Frankfurt).
• Halp: gehost bij AWS in de regio's VS-Oost-2 en VS-West-2.
• Bitbucket: repository's en functies van de belangrijkste applicaties worden gehost bij AWS in VS-Oost en VS-West.


Bekijk: https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/ voor meer informatie over de gegevenslocatie.

6.10. (e)

Wordt de jurisdictie over de contractvoorwaarden en over de gegevens verdeeld?

Het standaardrecht van het Atlassian-klantencontract is het Californische recht. Neem voor meer informatie contact op met ons Enterprise-salesteam.

6.10. (f)

Worden de services van de cloudprovider uitbesteed?

Atlassian werkt samen met externe onderaannemers voor de website, ontwikkeling van de applicatie, hosting, onderhoud, back-up, opslag, virtuele infrastructuur, verwerking van betalingen, analyses en andere services. Deze serviceproviders hebben mogelijk toegang tot PII of verwerken die om die services aan ons te leveren.

Atlassian maakt elk gebruik van onderaannemers die mogelijk de PII verwerken, aan de relevante klanten bekend via een kennisgeving voordat de verwerking plaatsvindt. Een externe lijst van onderaannemers waarmee Atlassian samenwerkt is te vinden op de pagina van Atlassian Subprocessors op: https://www.atlassian.com/legal/sub-processors. Op deze pagina worden bezoekers uitgenodigd zich te abonneren op een RSS-feed om op de hoogte te worden gehouden wanneer we nieuwe Atlassian-onderaannemers toevoegen.

6.10. (g)

Worden de services van de cloudprovider uitbesteed?

Als Atlassian externe leveranciers inschakelt, zorgen we dat we er zeker van zijn dat die samenwerkingen onze klanten of hun gegevens op geen enkele manier in gevaar brengen. De juridische en inkoopafdelingen van Atlassian beoordelen contracten, SLA's en het interne beleid van leveranciers om te bepalen of de leverancier voldoet aan de vereisten voor beveiliging, beschikbaarheid en vertrouwelijkheid. Ga voor meer informatie naar https://www.atlassian.com/trust/security/security-practices#supplier-risk-management

6.10. (h)

Hoe worden de gegevens die door de klant en de klanten van de klant worden verstrekt, verzameld, verwerkt en overgedragen?

Atlassian verwerkt informatie op een manier die verenigbaar is met de doeleinden waarvoor de informatie is verzameld of later door de persoon is goedgekeurd, en in het bijzonder in overeenstemming met het externe privacybeleid van Atlassian.

Gebruikersprivacy is belangrijk voor ons bij Atlassian, net als transparant zijn over hoe wij informatie over gebruikers hebben verzameld, gebruiken en delen. Ga voor meer informatie naar onze pagina Privacy bij Atlassian, onderdeel van het Atlassian Trust Center, op https://www.atlassian.com/trust/privacy, en ons Privacybeleid op https://www.atlassian.com/legal/privacy-policy.

6.10. (i)

Wat gebeurt er met de gegevens die naar de cloudprovider worden gestuurd na beëindiging van het contract?

Atlassian hanteert een standaard voor gegevensbehoud en -vernietiging, die aangeeft hoe lang we nodig hebben om verschillende soorten gegevens te bewaren. Gegevens worden geclassificeerd in overeenstemming met ons Atlassian-beleid inzake gegevensbeveiliging en levenscyclus van informatie, en op basis daarvan worden controles geïmplementeerd. Voor klantgegevens: na beëindiging van een Atlassian-contract worden de gegevens van een klantenteam verwijderd uit de live productiedatabase en worden alle bestandsbijlagen die rechtstreeks naar Atlassian zijn geüpload binnen 14 dagen verwijderd. De gegevens van het team blijven in versleutelde back-ups staan totdat de bewaartermijn van 90 dagen voor back-ups vervalt. Daarna worden de gegevens vernietigd in overeenstemming met ons Atlassian-beleid voor gegevensbehoud. In het geval dat een databaseherstel nodig is binnen 90 dagen na het verwijderen van de gevraagde gegevens, zal het operationele team de gegevens zo snel als redelijkerwijs mogelijk opnieuw verwijderen nadat het live productiesysteem volledig is hersteld. Ga voor meer informatie naar https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/