Beveiligingsmethoden

Ons team

We weten dat de meeste bedrijven dit zeggen, maar we zijn extreem trots op ons beveiligingsteam. We geloven dat we een team hebben samengesteld en ontwikkeld dat uit enige van de beste en slimste mensen in de branche bestaat. Ons beveiligingsteam wordt geleid door onze CISO in San Francisco en bestaat uit meer dan 100 mensen, verspreid over onze locaties in Sydney, Amsterdam, Bengaluru, Austin, Mountain View, San Francisco en New York, en nog wat externe teamleden. Dit team blijft groeien om de prioriteit die Atlassian toekent aan beveiliging te onderstrepen. We hebben meerdere subteams, waaronder:

• Productbeveiliging: verantwoordelijk voor de beveiliging van onze producten en platformen
• Ecosysteembeveiliging: verantwoordelijk voor de beveiliging van onze Marketplace en add-ons
• Detection and Response – responsible for detecting and responding to security incidents
• Red team - responsible for adversary emulation and exercising Detection and Response
• Beveiligingsarchitectuur: verantwoordelijk voor het vaststellen van de beveiligingsvereisten van onze producten en platformen
• Bedrijfsbeveiliging: verantwoordelijk voor onze interne beveiliging met betrekking tot ons bedrijfsnetwerk en onze zakelijke applicaties
• Vertrouwen: verantwoordelijk voor het volgen van en inspelen op de verwachtingen van onze klanten en het bieden van transparantie in onze processen en praktijken
• Ontwikkeling en SRE: verantwoordelijk voor het opbouwen en uitvoeren van hulpmiddelen voor het beveiligingsteam
• Bewustzijn en training: verantwoordelijk voor het veilig werken van onze werknemers en partners

Ons beveiligingsteam blijft zich uitbreiden, maar uiteindelijk is iedereen bij Atlassian onderdeel van onze missie om betere beveiliging mogelijk te maken en dit wordt ook aan al ons personeel duidelijk gemaakt gedurende hun tijd hier bij ons. Het is ons doel om de leider te zijn onder onze peers op het gebied van cloudbeveiliging, te voldoen aan alle klantvereisten voor cloudbeveiliging, de vereisten voor de beveiligingsnormen in de branche en certificeringen te overtreffen en met trots details te publiceren over hoe we onze klantgegevens beschermen. Onze doelen en visie zijn voor al ons personeel duidelijk gedurende hun tijd hier bij Atlassian.

Aanvullende programma's die we gebruiken om beveiliging te ondersteunen

We richten ons op de basisbeginselen van beveiliging, maar we gebruiken ook een scala aan programma's die er voor zorgen dat onze aanpak op het gebied van beveiliging ver blijft reiken en proactief is. Dit zijn onder andere:

Ons beveiligingsprogramma continu verbeteren

We zijn vastberaden om te zorgen dat ons beveiligingsprogramma baanbrekend blijft en we toonaangevend blijven in de branche. We weten dat we, om dat te bereiken, onze huidige beveiligingsaanpak doorlopend moeten beoordelen (en moeten vergelijken met anderen in de branche) en kansen voor verbetering moeten identificeren.

Om dit te doen hebben we verschillende looptijdbeoordelingen van ons beveiligingsprogramma uitgevoerd (en blijven we deze uitvoeren) aan de hand van onafhankelijke beveiligingsadviesbedrijven. In 2020 hebben we bovendien een beoordeling van ons algehele Vertrouwens- en beveiligingsprogramma door anderen in de branche laten uitvoeren. De resultaten van deze processen, inclusief belangrijke aanbevelingen, gebruiken we om eventuele hiaten op te vullen en verbeterkansen aan te grijpen.

We have also defined a series of programs across our various security – such as Product Security and Detection and Response – to guide our internal improvement. We have defined metrics to support each of these programs which we review through our Security Management Team. We use these metrics to identify and target areas for improvement across each of our core capabilities.

Meer informatie

Hoewel dit artikel een breed overzicht geeft van onze aanpak op het gebied van beveiliging, is er meer informatie over ons beveiligingsprogramma beschikbaar in ons Atlassian Trust Center. Er is ook een groot aantal specifieke webpagina's en whitepapers beschikbaar over de verschillende gebieden binnen ons beveiligingsprogramma, waaronder:

• Hoe Atlassian klantgegevens beheert
• Hoe wij externe beveiligingstests aanpakken
• Hoe wij het beheer van beveiligingsincidenten aanpakken
• Hoe wij kwetsbaarheidsbeheer aanpakken
• Gedeelde verantwoordelijkheden cloudbeveiliging
• Ons Atlassian Trust Management System
• Onze Atlassian-beleidsregels voor beveiliging en technologie

Toegang tot onze netwerken beveiligen met ZeroTrust

Atlassian beschermt toegang tot het zakelijke netwerk, interne toepassingen en cloudomgevingen met een concept dat ZeroTrust heet. Eenvoudig gezegd is de kernwaarde van ZeroTrust: 'never trust, always verify.'

ZeroTrust neemt afscheid van traditionele manieren om netwerkbeveiliging aan te passen, manieren die alleen afhankelijk zijn van authenticatie door een gebruiker om te bepalen of die gebruiker toegang krijgt tot resources op ons netwerk. Een dergelijke manier brengt het risico met zich mee dat een onbetrouwbaar en onveilig apparaat de beveiliging in gevaar kan brengen. Veel organisaties werken daarom tegenwoordig met een model waarin alleen vertrouwde apparaten toegang hebben tot het netwerk, met behulp van benaderingen zoals technologieën voor mobiel apparaatbeheer of het beperken van toegang op netwerkniveau tot een lijst van bekende apparaten.

Deze benaderingen zijn nuttig, maar missen granulariteit. De ZeroTrust-benadering van Atlassian zorgt er effectief voor dat de keuze voor of gebruikers toegang krijgen tot resources en services op onze netwerken niet alleen gebaseerd wordt op hun authenticatiegegevens, maar ook afhankelijk is van een dynamische beleidsbeslissing die rekening houdt met verscheidene factoren om toegang per resource toe te staan of te weigeren, op basis van de beveiligingssituatie van het apparaat van de gebruiker (ongeacht locatie).

Simpel gezegd: we hebben resources in drie niveaus onderverdeeld (op basis van relatief belang en relatieve gevoeligheid) op ons netwerk waar ZeroTrust mee werkt:

• Open niveau: elke zakelijke gebruiker die inlogt bij ons netwerk krijgt toegang tot deze services
• Laag niveau: toegang tot deze bronnen is alleen beschikbaar voor een zakelijke gebruiker die ingelogd is op ons netwerk via een vertrouwd zakelijk apparaat (een apparaat dat eigendom is van Atlassian en door Atlassian beheerd wordt) of een beheerd BYOD (een persoonlijk apparaat dat aangemeld is bij het MDM-programma van Atlassian)
• Hoog niveau: toegang tot deze resources is alleen beschikbaar voor zakelijke gebruikers die ingelogd zijn met een door Atlassian verstrekt zakelijk apparaat. Toegang tot onze productiediensten vanuit ons zakelijke netwerk is alleen mogelijk met een apparaat uit het hoge niveau en SAML-authenticatie

Toegang tot onze systemen en services veilig beheren

Atlassian heeft een goed gedefinieerd proces voor het inrichten (toewijzen of intrekken) van gebruikerstoegang voor alle systemen en services. We hebben een vaste workflow (synchronisatie van 8 uur) die ons HR-managementsysteem koppelt aan ons systeem voor het inrichten van toegang. We gebruiken toegangscontrole op basis van rollen, gebaseerd op vooraf gedefinieerde gebruikersprofielen, om er zeker van te zijn dat medewerkers alleen de geschikte toegang hebben voor hun taakprofiel. Alle gebruikersaccounts moeten door het management goedgekeurd zijn voordat ze toegang krijgen tot gegevens, applicatie, infrastructuur of netwerkonderdelen.

Door onze ZeroTrust-architectuur te ondersteunen, beheren we toegang tot onze zakelijke applicaties via een single-sign-onplatform. Om toegang te krijgen tot een van onze platformen moeten onze medewerkers zich aanmelden via dit platform en een tweede authenticatiefactor gebruiken. Gebruikers moeten zich authenticeren via U2F-sleutels of via een mobiele applicatie voor authenticatie die aan Atlassian-medewerkers is uitgegeven; we hebben minder veilige authenticatiemethoden zoals sms en OTP's via telefoons weggehaald. Atlassian heeft voor deze aanpak gekozen om er zeker van te zijn dat ons authenticatieproces goed bestand is tegen aanvallen met phishing- en man-in-the-middle-strategieën; alle systemen die codes versturen via sms-berichten kunnen worden gecompromitteerd door een ervaren aanvaller.

Onze eindpuntapparaten beveiligen

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.

Personeel van Atlassian dat via hun persoonlijke mobiele apparaten toegang wil tot veel van onze services moet zich aanmelden voor ons Mobile Device Management (MDM)-programma, als onderdeel van onze ZeroTrust-aanpak. Op deze manier kunnen wij er zeker van zijn dat alle mobiele apparaten die aangesloten zijn op ons netwerk voldoen aan onze minimumvereisten voor beveiliging. Hieronder vallen aspecten als versleuteling, apparaatvergrendeling, antimalware-software en OS-versies.

Alle in aanmerking komende medewerkers die deelnemen aan ons MDM-programma en dit naleven krijgen van Atlassian een maandelijkse vergoeding voor hun deelname.

Elk apparaat waarvan wordt vastgesteld dat het niet aan de compliance voldoet, zal ertoe leiden dat dat medewerker een e-mail krijgt met informatie over de non-compliance. Medewerkers krijgen dan 24 uur de tijd om de non-compliance te verhelpen voordat hun toegang tot dat apparaat ingetrokken wordt.

Configuraties in onze systemen beheren

We hebben een beperkte groep technici en architecten die software mogen installeren in onze productieomgeving. In de meeste gevallen kan er geen software geïnstalleerd worden. In onze productieomgevingen worden configuratiemanagementtools gebruikt om configuraties en wijzigingen in servers te beheren. Directe wijzigingen die in die systemen aangebracht worden kunnen overschreven worden door goedgekeurde configuraties die gepusht worden via die configuratiemanagementtools om consistentie te garanderen. We zijn afhankelijk van standaard Amazon Machine Images (AMI's) en alle wijzigingen aan onze AMI's of besturingssystemen moeten via ons standaard verandermanagementproces doorgevoerd worden, we houden uitzonderingsconfiguraties bij en rapporteren hierover en we isoleren resources zodat issues met services geen invloed hebben op andere services. We vertrouwen bovendien op ons Peer Review / Green Build (PRGB)-proces om ervoor te zorgen dat meerdere reviewers instemmen met tools voor configuratiebeheer. Alle builds zijn cryptografisch ondertekend en alleen ondertekende builds mogen in onze productieomgeving draaien.

Logboeken gebruiken

We gebruiken een SIEM-platform om logboeken uit verschillende bronnen te verzamelen en passen bewakingsregels toe op die verzamelde logboeken om verdachte activiteiten te markeren. Onze interne processen bepalen de prioriteiten van deze waarschuwingen, hoe ze verder onderzocht worden en hoe ze op de juiste manier worden geëscaleerd. Belangrijke systeemlogboeken worden doorgestuurd vanuit ieder systeem waarin logboeken alleen-lezen zijn. Het Atlassian Security-team maakt waarschuwingen aan op ons platform voor beveiligingsanalyses en controleert op tekenen van aantasting. Onze SRE-teams gebruiken dit 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.

Belangrijke systeemlogboeken worden gecombineerd in zowel een intern systeem voor logboekanalyse als een inbraakdetectiesysteem.

Logboeken zijn een belangrijk onderdeel van onze algemene strategie voor incidentdetectie en -respons, die uitgebreid wordt behandeld in de sectie 'Hoe we beveiligingsbedreigingen identificeren, er tegen beschermen en erop reageren'.

Management bedrijfscontinuïteit en disaster recovery

We geven veel om de verkracht van onze producten, niet in de laatste plaats omdat wij intern bij Atlassian op diezelfde producten vertrouwen. We erkennen dat verstoringen kunnen gebeuren. Daarom zijn we vastbesloten om ingebouwde processen te hebben om in te spelen op verstoringen en ze af te handelen met minimale gevolgen voor onze klanten als ze toch voorkomen. Onze programma's voor bedrijfscontinuïteit (BC) en disaster recovery (DR) leggen de verschillende activiteiten vast die worden uitgevoerd om die doelstellingen te bereiken.

De betrokkenheid van het leiderschap bij BC- en DR-planningsactiviteiten garandeert het nodige toezicht om er zeker van te zijn dat de verantwoordelijkheid voor veerkracht alle teams bereikt. Onze BC- en DR-planningsactiviteiten streven ernaar om de juiste balans te bereiken tussen kosten, voordelen en risico door middel van een analyse van de RTO (recovery time objectives) en RPO (recovery point objectives) van services. Deze analyse heeft ertoe geleid dat we een eenvoudig systeem van 4 niveaus hebben opgezet om services te groeperen op basis van hun respectievelijke vereisten voor herstel. Meer informatie over deze aanpak is te vinden op onze pagina over Hoe Atlassian klantgegevens beheert.

Onze BC- en DR-programma's omvatten de volgende activiteiten:

1. maatregelen voor ingebouwde redundantie om aan vereisten voor veerkracht te voldoen

2. testen en controleren van deze redundantiemaatregelen

3. leren van tests om onze BC- en DR-maatregelen doorlopend te blijven verbeteren

We bouwen onze producten zo dat we optimaal gebruik kunnen maken van redundantiemogelijkheden, zoals beschikbaarheidszones en -regio's, zoals aangeboden door onze cloudserviceproviders.

We bewaken continu een breed scala aan statistieken om potentiële problemen vroegtijdig op te sporen. Op basis van die statistieken worden waarschuwingen geconfigureerd om Site Reliability Engineers (SRE's) of de relevante teams van producttechnici op de hoogte te brengen wanneer de drempelwaarden worden overschreden zodat er snel actie ondernomen kan worden via ons proces voor incidentrespons. SRE's spelen ook een belangrijke rol in het vaststellen van hiaten in het DR-programma en werken samen met ons risico- en complianceteam om die hiaten te dichten. In elk van onze teams zit ook een DR-champion om de aspecten van disaster recovery voor dat team te overzien en te helpen bij het beheren ervan.

Onze DR-tests hebben betrekking op processen en technologie, inclusief relevante procesdocumentatie. De frequentie van DR-tests komt overeen met hoe cruciaal het niveau van iedere service is. Back-up- en herstelprocessen voor belangrijke klantgerichte systemen worden bijvoorbeeld elk kwartaal getest. We voeren handmatige tests en ad-hoc failovertests uit op onze systemen. Deze tests variëren van eenvoudigere tabletop-simulatieoefeningen tot ingewikkeldere failovertests van beschikbaarheidszones of -regio's. We zijn ijverig in het vastleggen en documenteren van de testresultaten, onafhankelijk van de complexiteit van de tests, om mogelijke verbeteringen of hiaten vast te stellen en te analyseren, om ze vervolgens af te handelen met behulp van Jira-tickets om doorlopende verbetering van het algemene proces te garanderen.

We voeren jaarlijks Business Impact Assessments (BIA's) uit om de risico's die bij deze kritieke services horen te beoordelen. De resultaten van deze BIA's helpen ons de strategie voor DR- en BC-inspanningen te bepalen. Hierdoor kunnen kritische services de plannen voor DR en BC effectief ontwikkelen.

Servicebeschikbaarheid

Naast bovenstaande maatregelen publiceren we ook de beschikbaarheidsstatus van onze services in realtime voor klanten die ons eigen Statuspage-product gebruiken. Als er problemen zijn met een van onze producten weten onze klanten dat zodra wij het weten.

Back-ups

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 voor onze Atlassian Cloud-producten, specifiek voor onze klant- en applicatiegegevens. Atlassian gebruikt 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 destructieve wijzigingen, 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 ondersteuningsdocumentatie voor je product.

Fysieke beveiliging

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. Dit beleid heeft betrekking op gebieden als veilige werkruimten, om onze IT-apparatuur op iedere locatie te beveiligen, toegang tot onze kantoren en gebouwen te beperken tot alleen het juiste personeel en fysieke in- en uitgangen te bewaken. Onze fysieke beveiligingsmaatregelen omvatten een bemande receptie tijdens kantooruren, verplichte registratie voor bezoekers, badges voor toegang tot niet-publieke ruimtes, samenwerking met het management van onze kantoorgebouwen voor toegang buiten kantooruren en videoregistratie bij in- en uitgangen, zowel voor hoofdingangen als laadgebieden.

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.

Gegevensversleuteling

Alle klantgegevens in Atlassian-cloudproducten worden versleuteld in transit bij publieke netwerken met behulp van TLS 1.2+ met Perfect Forward Secrecy (PFS) om onbevoegde openbaarmaking of wijziging te voorkomen. Dankzij onze implementatie van TLS zijn sterke versleuteling en codelengtes verplicht, waar ondersteund door de browser.

Harde schijven op servers die klantgegevens en bijlagen bevatten in Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie en Trello gebruiken de standaard AES-256-versleuteling at rest voor de volledige schijf. Raadpleeg de Roadmap van Atlassian Trust om op de hoogte te blijven van updates aan ons platform.

Codebeheer

Atlassian gebruikt de AWS Key Management Service (KMS) voor codebeheer. 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.

Tenantscheiding

Hoewel onze klanten een algemene cloudgebaseerde IT-infrastructuur delen wanneer ze de producten van Atlassian gebruiken, hebben we maatregelen getroffen om er zeker van te zijn dat ze logisch gescheiden zijn, zodat de acties van één klant de gegevens of service van andere klanten niet in gevaar kunnen brengen.

De aanpak van Atlassian om dit te bereiken verschilt in onze applicaties. We gebruiken voor Jira en Confluence Cloud een concept dat we 'tenantcontext' noemen om de logische scheiding van onze klanten te bereiken. Dit wordt zowel geïmplementeerd in de applicatiecode als beheerd door de Tenant Context Service (TCS) die we gebouwd hebben. Dit concept zorgt ervoor dat:

• De gegevens at-rest van iedere klant logisch gescheiden gehouden zijn van andere klanten
• Alle aanvragen die verwerkt worden door Jira en Confluence een 'tenant-specifieke' weergave hebben zodat ze geen invloed hebben op andere tenants

In brede zin werkt het TCS door een 'context' op te slaan voor individuele klanttenants. De context voor iedere tenant wordt gekoppeld aan een uniek ID dat centraal is opgeslagen door het TCS en dat een reeks metagegevens bevat die bij die tenant hoort (zoals in welke databases de tenant zit, welke licenties de tenant heeft, welke functies de tenant toegang toe heeft en andere configuratie-informatie). Als een klant Jira of Confluence Cloud gebruikt, gebruikt de TCS de tenant-ID om die metadata te ordenen en deze te koppelen aan alle activiteiten die de tenant in de applicatie uitvoert gedurende de sessie.

De context die de TCS levert, fungeert effectief als 'lens' waardoor alle interacties met klantgegevens plaatsvinden. Die lens is altijd beperkt tot één specifieke tenant. Op deze manier garanderen we dat één klanttenant geen toegang heeft tot de gegevens van een andere tenant, en dat één tenant geen invloed kan hebben op de service van een andere tenant.

Meer informatie over onze cloudarchitectuur is beschikbaar als onderdeel van onze cloudsupportresources.

De verantwoordelijkheid voor het beheren van klantgegevens delen

Atlassian neemt de verantwoordelijkheid op zich voor de beveiliging, beschikbaarheid en de prestaties van de applicaties die we leveren, de systemen waarop ze werken en de omgevingen waarin die systemen gehost worden. Beveiliging is echter een gedeelde verantwoordelijkheid van Atlassian en onze klant op vier specifieke gebieden:

Toegang tot klantgegevens beheren

We behandelen alle klantgegevens als even gevoelig en we hebben strenge controles geïmplementeerd voor deze gegevens. Onze interne werknemers en contractors krijgen bewustwordingstraining tijdens het onboardingproces. Hierin wordt het belang van en best practices voor omgang met klantgegevens behandeld.

Alleen geautoriseerde Atlassians hebben binnen Atlassian toegang tot de klantgegevens die opgeslagen zijn in onze applicaties. Authenticatie vindt plaats via openbare codes die met individuele wachtwoorden beschermd zijn, en servers staan alleen binnenkomende SSH-verbindingen toe van Atlassian en interne datacenter-locaties. Alle toegang is beperkt tot groepen die gemachtigd zijn, tenzij toegang wordt aangevraagd en de aanvraag wordt goedgekeurd. Hiervoor is aanvullende authenticatie met 2FA vereist.

Ons internationale supportteam maakt onderhouds- en supportprocessen mogelijk met strenge authenticatie- en autorisatiecontroles. Toegang tot gehoste applicaties en gegevens wordt mogelijk gemaakt om gezondheidscontroles en onderhoudswerkzaamheden aan systemen of applicaties uit te voeren, of op aanvraag van de klant via ons supportsysteem. Onze klanten krijgen ook opties om expliciete toestemming te geven aan supportmedewerkers die zij geschikt achten om toegang te krijgen tot hun gegevens via onze toestemmingscontrolechecker.

Ongeautoriseerde of ongepaste toegang tot klantgegevens wordt gezien als een beveiligingsincident en wordt afgehandeld volgens ons proces voor incidentmanagement. Dit proces omvat instructies voor het op de hoogte brengen van betrokken klanten als er sprake is van een beleidsschending.

Bewaring en verwijdering van gegevens

We hebben maatregelen ingevoerd zodat we kunnen reageren op verzoeken van gebruikers om persoonlijke gegevens te verwijderen en we helpen eindgebruikers met Atlassian-accounts om hun persoonlijke gegevens te verwijderen. We hebben bovendien import- en exporttools zodat onze gebruikers toegang hebben tot hun gegevens en deze kunnen importeren en exporteren met de tools van Atlassian.

Websites van klanten worden 15 dagen na afloop van de abonnementsperiode van een klant gedeactiveerd. Atlassian bewaart de gegevens van gedeactiveerde websites gedurende 15 dagen (voor evaluatiesites) of 60 dagen (voor betaalde abonnementssites) na afloop van de abonnementsperiode van een klant. Let op: bij Jira worden gegevens pas verwijderd wanneer je uitgeschreven bent bij alle Jira-producten waarop je eerst geabonneerd was.

Aanvullende informatie is te vinden op onze pagina Beveiligingsmethoden of in onze veelgestelde vragen over gegevensopslag.