Atlassian Cloud-architectuur en operationele werkwijzen (2023)

Atlassian Cloud-hostingarchitectuur

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

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

Beschikbaarheidszones

Elke beschikbaarheidszone is ontworpen om te worden geïsoleerd van storingen in de andere zones en om goedkope netwerkconnectiviteit met lage latentie te bieden aan andere AZ's in dezelfde regio. Deze multi-zone hoge beschikbaarheid is de eerste verdedigingslinie voor geografische en omgevingsrisico's en betekent dat services die in multi-AZ-implementaties worden uitgevoerd, bestand moeten zijn tegen AZ-storingen.

Jira en Confluence gebruiken de multi-AZ-implementatiemodus voor Amazon RDS (Amazon Relational Database Service). In een multi-AZ-implementatie voorziet en onderhoudt Amazon RDS een synchrone standby-replica in een ander AZ binnen dezelfde regio om redundantie en failover-mogelijkheden te bieden. De AZ-failover is geautomatiseerd en duurt doorgaans 60-120 seconden, zodat databasebewerkingen zo snel mogelijk kunnen worden hervat zonder administratieve tussenkomst. Opsgenie, Statuspage, Trello en Jira Align gebruiken vergelijkbare implementatiestrategieën, met kleine verschillen in replica-timing en failover-timing.

Gegevens locatie

Jira- en Confluence-gegevens bevinden zich in de regio die het dichtst bij de locatie ligt waar de meerderheid van uw gebruikers zich bevinden bij aanmelding. We weten echter dat sommigen van u misschien eisen dat uw gegevens op een bepaalde locatie blijven, dus bieden we gegevensopslag aan. Momenteel bieden we gegevensresidentie aan in de VS en de EU-regio's, evenals in Australië, met plannen om extra regio's toe te voegen. Voor informatie en om u aan te melden voor updates, zie onzedata residency pagina.

Gegevens voor Bitbucket bevinden zich in de regio US-Oost en we gebruiken US-West voor noodherstel.

Back-ups van gegevens

Bij Atlassian hebben we een uitgebreid back-upprogramma. Dit geldt ook voor onze interne systemen, waar onze back-upmaatregelen zijn ontworpen in overeenstemming met de vereisten voor systeemherstel. Met betrekking tot onze cloudproducten, en specifiek met betrekking tot u en uw applicatiegegevens, hebben we ook uitgebreide back-upmaatregelen getroffen. We gebruiken de snapshot-functie van Amazon RDS (Relational Database Service) om geautomatiseerde dagelijkse back-ups te maken van elke RDS-instantie.

Amazon RDS-snapshots worden 30 dagen bewaard met ondersteuning voor herstel naar een bepaald tijdstip en worden gecodeerd met AES-256-codering. Back-upgegevens worden niet offsite opgeslagen, maar worden gerepliceerd naar meerdere datacenters binnen een bepaalde AWS-regio. We voeren ook driemaandelijkse tests uit van onze back-ups.

Voor Bitbucket worden gegevens gerepliceerd naar een andere AWS-regio en worden er dagelijks onafhankelijke back-ups gemaakt binnen elke regio.

We gebruiken deze back-ups niet om door de klant geïnitieerde destructieve wijzigingen ongedaan te maken, zoals velden die zijn overschreven met scripts of verwijderde problemen, projecten of sites. Om gegevensverlies te voorkomen, raden we aan om regelmatig back-ups te maken. Lees meer over het maken van back-ups in de ondersteuningsdocumentatie voor uw product.

Beveiliging van datacenters

AWS onderhoudt meerdere certificeringen voor de bescherming van hun datacenters. Deze certificeringen hebben betrekking op fysieke en omgevingsbeveiliging, systeembeschikbaarheid, netwerk- en IP-backbone-toegang, klantvoorziening en probleembeheer. Toegang tot de datacenters is beperkt tot geautoriseerd personeel, zoals geverifieerd door middel van biometrische identiteitsverificatiemaatregelen. Fysieke beveiligingsmaatregelen omvatten: beveiligingspersoneel op locatie, videobewaking met gesloten circuit, mantraps en aanvullende maatregelen voor inbraakbeveiliging.

Bitbucket gebruikt NetApp CVS voor de bestandsopslag van repositories. CVS is een bestandssysteem dat wordt beheerd door NetApp en wordt gehost vanuit een NetApp-datacenter. NetApp volgt de vereisten van wereldwijde gegevensbeveiligingswetten die redelijke beveiligingsmaatregelen vereisen voor het opslaan, verzenden en verwerken van gegevens. Daarnaast maakt NetApp gebruik van zowel zelfbeoordelingen als externe auditors om ervoor te zorgen dat aan de nalevingsvereisten wordt voldaan. Voor meer informatie, zieBeveiligingspraktijken van NetAppsEnconformiteitscertificeringen.

Gedistribueerde services-architectuur

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

Multi-tenant architectuur

Bovenop onze cloudinfrastructuur hebben we een multi-tenant microservice-architectuur gebouwd en beheerd, samen met een gedeeld platform dat onze producten ondersteunt. In een multi-tenant architectuur bedient één enkele service meerdere klanten, inclusief databases en rekeninstances die nodig zijn om onze cloudproducten te laten draaien. Elke shard (in wezen een container – zie afbeelding 3 hieronder) bevat de gegevens voor meerdere tenants, maar de gegevens van elke tenant zijn geïsoleerd en niet toegankelijk voor andere tenants. Het is belangrijk op te merken dat we geen single tenant-architectuur aanbieden.

Onze microservices zijn gebouwd met de minste privileges in gedachten en ontworpen om de reikwijdte van zero-day-exploitatie te minimaliseren en de kans op laterale verplaatsing binnen onze cloudomgeving te verkleinen. Elke microservice heeft zijn eigen gegevensopslag die alleen toegankelijk is met het authenticatieprotocol voor die specifieke service, wat betekent dat geen enkele andere service lees- of schrijftoegang heeft tot die API.

We hebben ons gericht op het isoleren van microservices en gegevens, in plaats van het bieden van een specifieke infrastructuur per tenant, omdat dit de toegang tot de beperkte gegevens van een enkel systeem voor veel klanten vernauwt. Omdat de logica is ontkoppeld en gegevensauthenticatie en -autorisatie plaatsvinden op de applicatielaag, fungeert dit als een extra beveiligingscontrole wanneer verzoeken naar deze services worden verzonden. Dus als een microservice wordt gecompromitteerd, resulteert dit slechts in beperkte toegang tot de gegevens die een bepaalde service nodig heeft.

Tenantinrichting en levenscyclus

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

1. Handelssystemen worden onmiddellijk bijgewerkt met de nieuwste metadata en toegangscontrole-informatie voor die klant, en vervolgens stemt een provisioning-orkestratiesysteem de "status van de ingerichte resources" af op de licentiestatus door middel van een reeks tenant- en productgebeurtenissen.

Huurder evenementen

Deze gebeurtenissen zijn van invloed op de huurder als geheel en kunnen zijn:

• Aanmaak: er wordt een huurder aangemaakt en gebruikt voor gloednieuwe sites
• Vernietiging: een hele huurder wordt verwijderd

Productgebeurtenissen

• Activering: na activering van gelicentieerde producten of apps van derden
• Deactiveren: 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
• Un-suspension: na het ongedaan maken van de schorsing van een bepaald bestaand product, waardoor toegang wordt verleend tot een site waarvan ze eigenaar zijn
• Licentie-update: bevat informatie over het aantal licentieplaatsen voor een bepaald product en de status (actief/inactief)

2. Creatie van de klantensite en activering van de juiste set producten voor de klant. Het concept van een site is de container van meerdere producten waarvoor een licentie is verleend aan een bepaalde klant. (bijv. Confluence en Jira Software voor ＜sitenaam＞.atlassian.net).

4. Creatie en opslag van de klantsite en product(en) kernmetadata en configuratie.

5. Creatie en opslag van de site en product(en) identiteitsgegevens, zoals gebruikers, groepen, toestemmingen, enz.

6. Levering van productdatabases binnen een site, b.v. Jira-productfamilie, Confluence, Compass, Atlas.

7. Levering van de gelicentieerde apps van het product/de producten.

Scheiding huurder

Hoewel onze klanten een gemeenschappelijke cloudgebaseerde infrastructuur delen bij het gebruik van onze cloudproducten, hebben we maatregelen genomen om ervoor te zorgen dat ze logisch gescheiden zijn, zodat de acties van de ene klant de gegevens of service van andere klanten niet in gevaar kunnen brengen.

De aanpak van Atlassian om dit te bereiken verschilt per applicatie. In het geval van Jira en Confluence Cloud gebruiken we een concept waarnaar we verwijzen als de 'tenantcontext' om logische isolatie van onze klanten te bereiken. Dit wordt geïmplementeerd in zowel de applicatiecode als beheerd door iets dat we hebben gebouwd, de Tenant Context Service (TCS). Dit concept zorgt ervoor dat:

• De gegevens van elke klant worden logisch gescheiden gehouden van andere tenants wanneer ze in rust zijn
• Alle verzoeken die worden verwerkt door Jira of Confluence hebben een tenant-specifieke weergave, zodat andere tenants niet worden beïnvloed

In grote lijnen werkt de TCS door een context op te slaan voor individuele huurders van klanten. De context voor elke tenant is gekoppeld aan een uniek ID dat centraal is opgeslagen door de TCS, en omvat een reeks metagegevens die aan die tenant zijn gekoppeld, zoals in welke databases de tenant zich bevindt, welke licenties de tenant heeft, tot welke functies ze toegang hebben, en een reeks andere configuratie-informatie. Wanneer een klant Jira- of Confluence-cloud opent, gebruikt de TCS de tenant-ID om die metagegevens te verzamelen, die vervolgens worden gekoppeld aan alle bewerkingen die de tenant tijdens de sessie in de applicatie uitvoert.

Atlassiaanse randen

Uw gegevens worden ook beschermd door iets dat we een edge noemen: virtuele muren die we rond onze software bouwen. Wanneer een verzoek binnenkomt, wordt het naar de dichtstbijzijnde rand gestuurd. Door middel van een reeks validaties wordt het verzoek toegestaan ​​of geweigerd.

• Ze landen op de Atlassian-rand die zich het dichtst bij de gebruiker bevindt. De edge verifieert de sessie en identiteit van de gebruiker via uw identiteitssysteem.
• De edge bepaalt waar uw productgegevens zich bevinden, op basis van gegevens in de TCS-informatie.
• De edge stuurt het verzoek door naar de doelregio, waar het op een rekenknooppunt terechtkomt.
• Het knooppunt gebruikt het configuratiesysteem van de huurder om informatie te bepalen, zoals de licentie en de locatie van de database, en roept verschillende andere gegevensarchieven en services aan (bijvoorbeeld het mediaplatform dat afbeeldingen en bijlagen host) om de informatie op te halen die nodig is om aan het verzoek te voldoen.
• Het oorspronkelijke gebruikersverzoek met informatie die is samengesteld uit eerdere oproepen naar andere services.

Omdat onze cloudproducten gebruikmaken van een multitenant-architectuur, kunnen we extra beveiligingscontroles toevoegen aan de ontkoppelde applicatielogica. Een monolithische toepassing per tenant introduceert doorgaans geen verdere autorisatiecontroles of snelheidsbeperkingen, bijvoorbeeld voor een groot aantal query's of exports. De impact van een enkele zero-day wordt drastisch verminderd naarmate de reikwijdte van de services wordt verkleind.

Daarnaast hebben we aanvullende preventieve controles ingebouwd in onze producten die volledig worden gehost op ons Atlassian-platform. De primaire preventieve controles omvatten:

• Serviceverificatie en autorisatie
• Tenant-contextservice
• Sleutelbeheer
• Data encryptie

Serviceverificatie en autorisatie

Ons platform gebruikt een model met de minste bevoegdheden voor toegang tot gegevens. Dit betekent dat alle gegevens beperkt zijn tot alleen de dienst die verantwoordelijk is voor het opslaan, verwerken of ophalen ervan. De mediaservices, waarmee je een consistente ervaring hebt met het uploaden en downloaden van bestanden in al onze cloudproducten, hebben bijvoorbeeld speciale opslagruimte waar geen andere services bij Atlassian toegang toe hebben. Elke service die toegang tot de media-inhoud vereist, moet communiceren met de mediaservices-API. Dientengevolge dwingt sterke authenticatie en autorisatie op de servicelaag ook tot een sterke scheiding van taken en minimale toegang tot gegevens.

We gebruiken JSON-webtokens (JWT's) om ondertekeningsbevoegdheid buiten de applicatie te garanderen, dus onze identiteitssystemen en tenantcontext zijn de bron van waarheid. Tokens kunnen voor niets anders worden gebruikt dan waarvoor ze zijn geautoriseerd. Wanneer u of iemand in uw team een ​​microservice of shard aanroept, worden de tokens doorgegeven aan uw identiteitssysteem en daarmee gevalideerd. Dit proces zorgt ervoor dat het token actueel en ondertekend is voordat de juiste gegevens worden gedeeld. In combinatie met de autorisatie en authenticatie die nodig is om toegang te krijgen tot deze microservices, is de reikwijdte van een service beperkt.

We weten echter dat identiteitssystemen soms kunnen worden aangetast. Om dit risico te beperken, gebruiken we twee mechanismen. Ten eerste worden TCS en de identiteitsproxy's sterk gerepliceerd. We hebben een TCS-zijspan voor bijna elke microservice en we gebruiken proxy-zijspannen die uitlopen naar de identiteitsautoriteit, dus er zijn altijd duizenden van deze services actief. Als er anamolusgedrag is in een of meer, kunnen we dat snel oppikken en het probleem oplossen.

Daarnaast wachten we niet tot iemand een kwetsbaarheid vindt in onze producten of platform. We identificeren deze scenario's actief, zodat de impact voor u minimaal is en we voeren een aantal beveiligingsprogramma's uit om beveiligingsbedreigingen te identificeren, op te sporen en erop te reageren.

Tenant-contextservice

We zorgen ervoor dat verzoeken aan microservices metadata bevatten over de klant - of huurder - die om toegang vraagt. Dit wordt de tenantcontextservice genoemd. Het wordt rechtstreeks ingevuld vanuit onze bevoorradingssystemen. Wanneer een verzoek wordt gestart, wordt de context gelezen en geïnternaliseerd in de lopende servicecode, die wordt gebruikt om de gebruiker te autoriseren. Alle servicetoegang, en dus gegevenstoegang, in Jira en Confluence vereist deze tenantcontext, anders wordt de aanvraag afgewezen.

Serviceverificatie en -autorisatie wordt toegepast via het Atlassian Service Authentication Protocol (ASAP). Een expliciete toelatingslijst bepaalt welke services mogen communiceren, en autorisatiegegevens specificeren welke opdrachten en paden beschikbaar zijn. Dit beperkt de mogelijke zijdelingse verplaatsing van een gecompromitteerde service.

Serviceverificatie en -autorisatie, evenals uitgaand verkeer, worden beheerd door een reeks speciale proxy's. Dit verwijdert de mogelijkheid voor kwetsbaarheden in de toepassingscode om deze controles te beïnvloeden. Externe code-uitvoering vereist het compromitteren van de onderliggende host en het omzeilen van de Docker-containergrenzen - niet alleen de mogelijkheid om applicatielogica te wijzigen. Integendeel, onze inbraakdetectie op hostniveau signaleert discrepanties.

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

Data encryptie

Klantgegevens in onze Atlassian-cloudproducten worden tijdens de overdracht via openbare netwerken versleuteld met behulp van TLS 1.2+ met Perfect Forward Secrecy (PFS) om ze te beschermen tegen ongeoorloofde openbaarmaking of wijziging. Onze implementatie van TLS dwingt het gebruik van sterke cijfers en sleutellengtes af waar de browser dit ondersteunt.

Datadrives op servers met klantgegevens en bijlagen in Jira Software Cloud, Jira Service Management Cloud, Jira Work Management, BitbucketCloud, Confluence Cloud, Statuspage, Opsgenie en Trello gebruiken volledige schijf, industriestandaard AES-256-encryptie in rust.

PII verzonden via een datatransmissienetwerk is onderworpen aan passende controles die zijn ontworpen om ervoor te zorgen dat gegevens de beoogde bestemming bereiken. Het interne cryptografie- en encryptiebeleid van Atlassian zet de algemene principes uiteen voor de implementatie door Atlassian van encryptie- en cryptografiemechanismen om de risico's te beperken die gepaard gaan met het opslaan van PII en het verzenden ervan via netwerken. Het type versleutelingsalgoritme dat wordt gebruikt om PII te versleutelen, moet rekening houden met het classificatieniveau van de PII in overeenstemming met Atlassian's interne Data Security & Information Lifecycle Management. Raadpleeg onze privacypagina voor meer informatie over hoe we klantgegevens verzamelen, delen en gebruiken.

Raadpleeg onze cloud-roadmap om op de hoogte te blijven van aanvullende mogelijkheden voor gegevensversleuteling.

Sleutelbeheer

Bij Atlassian gebruiken we de AWS Key Management Service (KMS) voor sleutelbeheer. Om de privacy van uw gegevens verder te waarborgen, is KMS de maker en geheime opslagplaats voor deze sleutels. Het coderings-, decoderings- en sleutelbeheerproces wordt regelmatig intern geïnspecteerd en geverifieerd door AWS als onderdeel van hun bestaande interne validatieprocessen. Voor elke sleutel wordt een eigenaar toegewezen die verantwoordelijk is voor het waarborgen van het juiste niveau van beveiligingscontroles op sleutels. Door Atlassian beheerde sleutels worden gerouleerd bij relevante wijzigingen van rollen of arbeidsstatus.

We maken ook gebruik van envelopversleuteling. AWS heeft de hoofdsleutel die we nooit kunnen zien en voor verzoeken om sleutelversleuteling of ontsleuteling zijn de juiste AWS-rollen en machtigingen vereist. En wanneer we envelopversleuteling gebruiken om sleutels voor individuele klanten te bouwen of te genereren, hebben we verschillende gegevenssleutels voor verschillende soorten gegevens via onze gegevensarchieven. Daarnaast hebben we een coderingsbenadering voor de interne applicatielaag die back-upgegevenssleutels biedt in andere AWS-regio's. Sleutels worden jaarlijks automatisch geroteerd en dezelfde gegevenssleutel wordt niet gebruikt voor meer dan 100.000 gegevenselementen.

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

AWS KMS kan worden geïntegreerd met AWS CloudTrail in uw AWS-account om u te voorzien van logboeken van al het sleutelgebruik. Deze oplossing maakt versleuteling van uw gegevens mogelijk op verschillende lagen in de applicaties, zoals databases, bestandsopslag, evenals onze interne caches en gebeurteniswachtrijen. Gedurende het hele proces zal er geen invloed zijn op de bruikbaarheid van het product.