Atlassian Cloud-architectuur en operationele werkwijzen

Atlassian Cloud-hostingarchitectuur

We gebruiken Amazon Web Services (AWS) als cloudserviceprovider en de zeer beschikbare datacenterfaciliteiten in meerdere regio's wereldwijd. Elke AWS-regio is een afzonderlijke geografische locatie met meerdere, geïsoleerde en fysiek gescheiden groepen datacenters die bekend staan als Availability Zones (AZ's).

We maken gebruik van de computer-, opslag-, netwerk- en datadiensten van AWS om onze producten en platformcomponenten te bouwen. Zo kunnen we redundantiemogelijkheden van AWS gebruiken, zoals beschikbaarheidszones en -regio's.

Beschikbaarheidszones (AZ's)

Elke Availability Zone is ontworpen om geïsoleerd te zijn van storingen in andere AZ's en om goedkope netwerkconnectiviteit met lage latentie te bieden aan andere AZ's in dezelfde regio. Deze hoge beschikbaarheid in meerdere zones is de eerste verdedigingslinie tegen geografische en milieurisico's en houdt in dat services die draaien in implementaties met meerdere AZ's, bestand zijn tegen storingen in een AZ.

Jira en Confluence gebruiken de implementatiemodus met meerdere AZ's voor Amazon RDS (Amazon Relational Database Service). Amazon RDS levert en onderhoudt in een implementatie met meerdere AZ's een synchrone replica die in een andere AZ in dezelfde regio op stand-by staat om redundantie en failover-mogelijkheden te bieden. De AZ-failover is geautomatiseerd en duurt over het algemeen 60-120 seconden, zodat databasebewerkingen zo snel mogelijk kunnen worden voortgezet zonder administratieve tussenkomst. Opsgenie, Statuspage, Trello en Jira Align maken gebruik van vergelijkbare implementatiestrategieën, met kleine variaties in de timing van replica's en failover.

Locatie van gegevens

Jira- en Confluence-gegevens bevinden zich in de regio die het dichtst bij de plek ligt waar de meerderheid van je gebruikers zich bevindt bij het aanmelden. We weten echter dat voor sommigen van jullie de gegevens op een bepaalde locatie moeten blijven, dus bieden we wel gegevenslocatie aan. Momenteel bieden we gegevenslocatie aan in de VS en EU-regio's, evenals Australië, en hebben we plannen om extra regio's toe te voegen. Zie onze pagina gegevenslocatie voor meer informatie en om je aan te melden voor updates.

Data for Bitbucket is located in two different availability zones in the US-East region.

Back-ups van gegevens

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.

For Bitbucket, storage snapshots are retained for 7 days with support for point-in-time recovery.

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.

Beveiliging van datacenters

AWS onderhoudt meerdere certificeringen voor de bescherming van hun datacenters. Deze certificeringen hebben betrekking op fysieke en milieubeveiliging, 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: bewakers op locatie, videobewaking, toegangssluizen en aanvullende maatregelen voor inbraakbeveiliging.

Architectuur voor gedistribueerde services

Met deze AWS-architectuur hosten we een aantal platform- en productservices die in onze oplossingen worden gebruikt. Dit omvat platformmogelijkheden die worden gedeeld en gebruikt voor meerdere Atlassian-producten, zoals Media, Identity en Commerce, ervaringen zoals onze Editor en productspecifieke mogelijkheden, zoals de Jira Issue-service en Confluence Analyses.

Architectuur met meerdere tenants

Naast onze cloudinfrastructuur hebben we een multi-tenant microservices-architectuur opgezet met een gedeeld platform dat onze producten ondersteunt. In een multi-tenantarchitectuur bedient één enkele service meerdere organisaties, waaronder de databases en computerinstallaties die nodig zijn om onze cloudproducten te kunnen draaien. Elke scherf (in wezen een container – zie figuur 3 hieronder) bevat de gegevens voor meerdere huurders, maar de gegevens van elke huurder zijn geïsoleerd en ontoegankelijk voor andere huurders. Het is belangrijk op te merken dat we geen single-tenantarchitectuur aanbieden.

Registratie en levenscyclus van tenants

Wanneer een nieuwe klant wordt geregistreerd, activeert een reeks gebeurtenissen de orkestratie van gedistribueerde services en het registreren van gegevensopslag. Deze gebeurtenissen kunnen over het algemeen worden toegewezen aan een van de zeven stappen in de levenscyclus:

1. Commerce-systemen worden onmiddellijk bijgewerkt met de nieuwste metagegevens en toegangsbeheerinformatie voor die klant, en vervolgens stemt een provisioning-orkestratiesysteem de "status van de geregistreerde resources" af op de licentiestatus via een reeks tenant- en productgebeurtenissen.

Tenantgebeurtenissen

Deze gebeurtenissen hebben gevolgen voor de tenant als geheel en kunnen mogelijk deze opties zijn:

• Creatie: er wordt een tenant gemaakt en gebruikt voor gloednieuwe sites
• Vernietiging: een volledige tenant wordt verwijderd

Productgebeurtenissen

• Activering: na de activering van gelicentieerde producten of apps van derden
• Deactivering: na het deactiveren van bepaalde producten of apps
• Opschorting: na de opschorting van een bepaald bestaand product, waardoor de toegang tot een bepaalde site waarvan zij eigenaar zijn, wordt uitgeschakeld
• Opschorting opheffen: na de opheffing van de opschorting van een bepaald bestaand product, waardoor toegang wordt verleend tot een site waarvan zij eigenaar zijn
• Licentie-update: bevat informatie over het aantal licenties voor een bepaald product en de status ervan (actief/inactief)

2. Creatie van de klantsite en activering van de juiste set producten voor de klant. Het concept van een site is de container van meerdere producten die gelicenseerd zijn aan een bepaalde klant. (bijv. Confluence en Jira Software voor ＜site-name＞.atlassian.net).

Tenantscheiding

Hoewel onze klanten een algemene cloudgebaseerde infrastructuur delen wanneer ze onze cloudproducten 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 tenantcontextservice (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 impact 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 unieke ID die centraal is opgeslagen door het TCS en die 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.

Atlassian-edges

Je gegevens worden ook beschermd door iets dat we een edge noemen: virtuele muren die we om onze software bouwen. Zodra een aanvraag binnenkomt, wordt deze naar de dichtstbijzijnde edge gestuurd. Door middel van een reeks validaties wordt de aanvraag toegestaan of geweigerd.

• Ze belanden op de Atlassian-edge die het dichtst bij de gebruiker zit. De edge verifieert de sessie en identiteit van de gebruiker via je identiteitssysteem.
• De edge bepaalt waar je productgegevens zich bevinden, op basis van gegevens in de TCS-informatie.
• De edge stuurt de aanvraag door naar het doelgebied, waar het op een computingnode terechtkomt.
• De node gebruikt het tenantconfiguratiesysteem om informatie vast te stellen, zoals de licentie en databaselocatie, en vraagt bij verschillende andere gegevensopslagplaatsen en -services (bijv. het Mediaplatform dat afbeeldingen en bijlagen host) informatie op die nodig is om aan de aanvraag te voldoen.
• De oorspronkelijke gebruikersaanvraag met informatie die is samengesteld uit eerdere oproepen naar andere services.

Verificatie en autorisatie van services

Ons platform maakt gebruik van het minste-privilege-model bij toegang tot gegevens. Dit betekent dat alle gegevens alleen toegankelijk zijn voor de service die verantwoordelijk is voor het opslaan, verwerken of ophalen ervan. De mediaservices bijvoorbeeld, die voor een consistente ervaring zorgen tijdens het uploaden en downloaden van bestanden in onze cloudproducten, hebben speciale opslagvoorzieningen waar geen andere service bij Atlassian toegang toe heeft. Elke service die toegang tot de mediacontent vereist, moet communiceren met de API van de mediaservices. Als gevolg hiervan zorgt sterke authenticatie en autorisatie op de servicelaag ook voor een sterke scheiding van taken en toegang tot gegevens met het minste-privilege-principe.

We gebruiken JSON-webtokens (JWT's) om tekenbevoegdheid buiten de applicatie te garanderen, dus onze identiteitssystemen en tenantcontext zijn de bron van waarheid. Tokens kunnen alleen gebruikt worden voor hetgeen waarvoor ze geautoriseerd zijn. Wanneer jij of iemand in je team een aanvraag doet bij een microservice of shard, worden de tokens doorgegeven aan je identiteitssysteem en aan de hand daarvan gevalideerd. Dit proces zorgt ervoor dat het token actueel en getekend is voordat de juiste gegevens worden gedeeld. In combinatie met de autorisatie en authenticatie die nodig zijn om toegang te krijgen tot deze microservices, wordt een service beperkt in scope als deze wordt aangetast.

We weten echter dat identiteitssystemen soms gecompromitteerd kunnen raken. Om dit risico te beperken gebruiken we twee mechanismen. Ten eerste worden de TCS en de identiteitsproxy's sterk gerepliceerd. We hebben een TCS-replica voor bijna elke microservice en we gebruiken proxy-replica's die vertakken naar de ID-autoriteit, dus er zijn altijd duizenden van deze services actief. Als er sprake is van afwijkend gedrag bij een of meer services, kunnen we dat snel oppikken en het probleem verhelpen.

Daarnaast wachten we niet af tot iemand een kwetsbaarheid vindt in onze producten of ons platform. We identificeren deze scenario's actief, zodat het minimale impact op je heeft en we draaien een aantal beveiligingsprogramma's om veiligheidsrisico's te identificeren, te detecteren en erop te reageren.

Tenantcontextservice

We zorgen ervoor dat verzoeken aan microservices metadata bevatten over de klant of de tenant die om toegang vraagt. Dit wordt de tenantcontextservice genoemd. Het wordt rechtstreeks vanuit onze provisioningssystemen ingevuld. Zodra een aanvraag wordt gestart, wordt de context gelezen en opgenomen in de actieve servicecode die gebruikt wordt om de gebruiker te machtigen. Alle servicetoegang, en dus gegevenstoegang, in Jira en Confluence vereisen deze tenantcontext, want anders wordt de aanvraag afgewezen.

Serviceverificatie en -autorisatie worden toegepast via Atlassian-serviceauthenticatieprotocol (ASAP). Een expliciete allowlist bepaalt welke services mogen communiceren en autorisatiedetails tonen welke opdrachten en paden beschikbaar zijn. Dit beperkt mogelijke zijwaartse bewegingen van een gecompromitteerde service.

Serviceverificatie en -autorisatie, evenals uitgaand verkeer, worden beheerd door een reeks aparte proxy's. Hierdoor kunnen kwetsbaarheden in applicatiecodes geen impact meer hebben op deze beheermaatregelen. Het uitvoeren van externe code vereist niet alleen de mogelijkheid om applicatielogica te wijzigen, maar ook het compromitteren van de onderliggende host en het omzeilen van de Docker-containergrenzen. In plaats daarvan markeert onze inbraakdetectie op hostniveau afwijkingen.

Deze proxy's beperken het gedrag van uitgaand verkeer op basis van het beoogde gedrag van de service. Services die geen webhooks hoeven uit te zenden of niet hoeven te communiceren met andere microservices mogen dit niet doen.

Gegevenscodering

Klantgegevens in onze 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 Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Jira Product Discovery, Statuspage, Opsgenie en Trello gebruiken de standaard AES-256-versleuteling in rust voor de volledige schijf.

PII transmitted using a data-transmission network are subject to appropriate controls designed to ensure that data reaches its intended destination. Atlassian's internal Cryptography & Encryption Policy sets out the general principles for Atlassian's implementation of encryption & cryptography mechanisms to mitigate the risks involved in storing PII and transmitting it over networks. The type of encryption algorithm used to encrypt PII must take into account the classification level of the PII in accordance with Atlassian's internal Data Security & Information Lifecycle Management. To learn more about how we collect, share, and use customer data, refer to our privacy page.

To keep up to date on additional data encryption capabilities, see our cloud roadmap.

Codebeheer

Bij Atlassian gebruiken we de AWS Key Management Service (KMS) voor codebeheer. Om de privacy van je gegevens nog meer te waarborgen is KMS de initiator en geheime opslagplaats voor deze codes. 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 code. Deze eigenaar is er verantwoordelijk voor dat het juiste niveau aan beveiligingscontroles wordt toegepast op de codes. Door Atlassian beheerde codes worden geroteerd als er relevante wijzigingen van rollen of gebruiksstatus plaatsvinden.

We maken ook gebruik van envelopversleuteling. AWS beschikt over de mastercode die nooit zichtbaar is voor ons, en voor alle aanvragen voor versleuteling of ontsleuteling van code zijn de juiste AWS-rollen en -rechten vereist. En wanneer we envelopversleuteling gebruiken om codes voor individuele klanten te bouwen of te genereren, gebruiken we verschillende gegevenscodes voor verschillende soorten gegevens via onze gegevensopslag. Daarnaast hebben we een versleutelingsbenadering van de interne applicatielaag die back-upgegevenscodes in andere AWS-regio's biedt. Codes worden elk jaar automatisch geroteerd en dezelfde gegevenscode wordt niet gebruikt voor meer dan 100.000 gegevenselementen.

Binnenkort bieden we versleuteling voor BYOK (Je eigen code inbrengen), zodat je je cloudproductgegevens kunt versleutelen met zelfbeheerde codes in AWS KMS. Met BYOK heb je volledige controle over het beheer van je codes en kun je op elk moment toegang verlenen of intrekken, zowel aan je eigen eindgebruikers als voor Atlassian-systemen.

AWS KMS kan worden geïntegreerd met AWS CloudTrail in je AWS-account zodat je toegang hebt tot logs van al het codegebruik. Deze oplossing maakt versleuteling van je gegevens mogelijk op verschillende lagen in de toepassingen, zoals databases, bestandsopslag en onze interne caches en wachtrijen voor gebeurtenissen. Gedurende het hele proces zal er geen impact zijn op de bruikbaarheid van het product.