Atlassian Cloud
Atlassian Cloud-architectuur en operationele werkwijzen
Leer meer over de Atlassian Cloud-architectuur en de operationele werkwijzen die we gebruiken
Introductie
Atlassian-cloudproducten en -gegevens worden gehost op de beste cloudprovider in de branche, 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-Macros-platform draaien.
Cloud-infrastructuur
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.
De gegevens voor Bitbucket bevinden zich in twee verschillende beschikbaarheidszones in de regio VS-Oost.
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, en 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 datacenters binnen een specifieke AWS-regio. Bovendien testen we onze back-ups ieder kwartaal.
Voor Bitbucket worden momentopnamen van de opslag 7 dagen bewaard, met ondersteuning voor herstel op een bepaald moment.
We gebruiken deze back-ups niet om door klanten geïnitieerde vernietigende 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 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 datacenters wordt beperkt tot bevoegd personeel en gecontroleerd met biometrische identiteitscontroles. Fysieke beveiligingsmaatregelen omvatten: bewakers op locatie, videobewaking, toegangssluizen en aanvullende maatregelen voor inbraakbeveiliging.
Cloud-platformarchitectuur
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.
Afbeelding 1
Atlassian-ontwikkelaars leveren deze services via een intern ontwikkeld platform-as-a-service (PaaS), Micros genaamd, dat automatisch de implementatie van gedeelde services, infrastructuur, gegevensopslag en hun beheermogelijkheden orkestreert, inclusief beveiligings- en compliance-controlevereisten (zie figuur 1 hierboven). Een Atlassian-product bestaat doorgaans uit meerdere "containerservices" die op AWS worden geïmplementeerd met behulp van Micros. Atlassian-producten maken gebruik van kernplatformmogelijkheden (zie figuur 2 hieronder) die variëren van verzoekroutering tot binaire objectopslag, verificatie/autorisatie, transactionele door gebruikers gegenereerde inhoud (UGC) en entiteitsrelaties, datameren, gemeenschappelijke logboekregistratie, verzoektracering, waarneembaarheid en analytische services. Deze microservices worden gebouwd met behulp van goedgekeurde technische stapels die zijn gestandaardiseerd op platformniveau:
Afbeelding 2
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.
Figuur 3
Onze microservices zijn gebouwd op basis van het principe 'minste privilege' en ontworpen om de scope van een 'zero-day'-aanval te minimaliseren en om de kans op laterale bewegingen binnen onze cloudomgeving te verkleinen. Elke microservice heeft zijn eigen gegevensopslag die alleen toegankelijk is met het verificatieprotocol voor die specifieke service. Dit 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 een speciale infrastructuur per tenant aan te bieden, omdat het de toegang tot het beperkte gegevensbereik van één systeem voor veel klanten beperkt. Omdat de logica is losgekoppeld en gegevensverificatie en autorisatie op de applicatielaag plaatsvindt, fungeert dit als een aanvullende beveiligingscontrole omdat aanvragen naar deze services worden verzonden. Dus als een microservice wordt aangetast, zal dit slechts resulteren in beperkte toegang tot de gegevens die een bepaalde service vereist.
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).
Figuur 4
3. Registratie van producten binnen de klantlocatie in de aangewezen regio.
Wanneer een product wordt geregistreerd, wordt het grootste deel van de inhoud in de buurt gehost van de plaats waar gebruikers het openen. Om de productprestaties te optimaliseren, beperken we de verplaatsing van gegevens niet wanneer deze wereldwijd wordt gehost en kunnen we indien nodig gegevens tussen regio's verplaatsen.
Voor sommige van onze producten bieden we ook gegevenslocatie aan. Gegevenslocatie stelt klanten in staat om te kiezen of productgegevens wereldwijd worden verspreid of op hun plaats worden gehouden op een van onze gedefinieerde geografische locaties.
4. Creatie en opslag van de klantsite en de kernmetadata en configuratie van het product.
5. Creatie en opslag van de site en de identiteitsgegevens van het product, zoals gebruikers, groepen, rechten, etc.
6. Registratie van productdatabases binnen een site, bijv. Jira-reeks van producten, Confluence, Compass, Atlas.
7. Registratie van de gelicentieerde apps van het product.
Figuur 5
Figuur 5 hierboven laat zien hoe de site van een klant wordt geïmplementeerd in onze gedistribueerde architectuur, niet alleen in één database of opslag. Dit omvat meerdere fysieke en logische locaties die metagegevens, configuratiegegevens, productgegevens, platformgegevens en andere gerelateerde site-informatie opslaan.
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.
Beveiligingsfuncties
Omdat onze cloudproducten gebruikmaken van een architectuur met meerdere tenants, kunnen we extra beveiligingscontroles aanbrengen in de losgekoppelde applicatielogica. Een monolithische applicatie per tenant zou doorgaans geen verdere autorisatiecontroles of snelheidsbeperking introduceren, bijvoorbeeld voor een groot aantal query's of exports. De impact van een enkele 'zero-day' wordt drastisch verminderd naarmate de scope van de services wordt verkleind.
Daarnaast hebben we extra preventieve controles ingebouwd in onze producten die volledig worden gehost op ons Atlassian-platform. De primaire preventieve controles omvatten:
- Verificatie en autorisatie van services
- Tenantcontextservice
- Codebeheer
- Gegevenscodering
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.
Data drives on servers holding customer data and attachments in Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie, and Trello use full disk, industry-standard AES-256 encryption at rest.
Persoonlijk identificeerbare informatie (PII) die via een datatransmissienetwerk wordt verzonden, is onderhevig aan toepasselijke controles om ervoor te zorgen dat de gegevens de beoogde bestemming bereiken. Het interne cryptografie- en versleutelingsbeleid van Atlassian beschrijft de algemene principes voor de implementatie van versleutelings- en cryptografiemechanismen van Atlassian 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 het interne Gegevensbeveiligings- en informatielevenscyclusbeheer van Atlassian. Raadpleeg onze privacypagina voor meer informatie over hoe we klantgegevens verzamelen, delen en gebruiken.
Zie onze cloudroadmap om op de hoogte te blijven van aanvullende mogelijkheden voor gegevensversleuteling.
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, decodering en codebeheer 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.