Praktyki operacyjne i architektura Atlassian Cloud

Architektura hostingu Atlassian Cloud

Korzystamy z Amazon Web Services (AWS) jako dostawcy usług w chmurze i ich centrów danych o wysokiej dostępności zlokalizowanych w wielu regionach na całym świecie. Każdy region AWS jest odrębną lokalizacją geograficzną z wieloma odizolowanymi i fizycznie oddzielonymi od siebie obszarami zwanymi strefami dostępności (Availability Zone, AZ).

Podczas opracowywania komponentów naszych produktów i platform korzystamy z usług danych, obliczeniowych, magazynowania i sieciowych AWS oraz możliwości nadmiarowości, które oferuje AWS, takich jak strefy dostępności i regiony.

Strefy dostępności

Każda strefa dostępności jest zaprojektowana tak, aby była odizolowana od awarii w innych strefach, a jednocześnie zapewniała niedrogą łączność sieciową o małych opóźnieniach z innymi strefami AZ należącymi do tego samego regionu. Wysoka dostępność wynikająca z zastosowania wielu stref stanowi pierwszą linię obrony przed zagrożeniami geograficznymi oraz środowiskowymi i oznacza, że usługi działające w oparciu o wdrożenia w wielu strefach AZ powinny być odporne na awarię w pojedynczej strefie AZ.

Produkty Jira i Confluence wykorzystują tryb wdrażania w wielu strefach AZ usługi Amazon RDS (Amazon Relational Database Service). W takim trybie wdrożenia usługa Amazon RDS inicjuje i utrzymuje synchroniczną replikę rezerwową w różnych strefach AZ tego samego regionu, zapewniając w ten sposób nadmiarowość i możliwość pracy w trybie awaryjnym. Przełączanie awaryjne między strefami dostępności odbywa się automatycznie i trwa 60–120 sekund, umożliwiając możliwie jak najszybsze przywrócenie działania baz danych bez konieczności interwencji administracyjnej. Produkty Opsgenie, Statuspage, Trello i Jira Align wykorzystują podobne strategie wdrażania. Niewielkie różnice dotyczą jedynie czasu tworzenia replik i przełączania awaryjnego.

Lokalizacja danych

Dane produktów Jira i Confluence są przechowywane w regionie najbliższym lokalizacji większości użytkowników wskazanej podczas rejestracji. Dane dla Bitbucket znajdują się w dwóch różnych strefach dostępności w regionie USA-East.

Rozumiemy jednak, że niektórzy mogą wymagać, aby dane pozostawały w określonej lokalizacji; dlatego oferujemy opcje jurysdykcji danych. Obecnie jurysdykcja danych jest dostępna w przypadku produktów Jira, Jira Service Management, Jira Product Discovery i Confluence w 11 regionach, w tym w USA, UE, Wielkiej Brytanii, Australii, Kanadzie, Niemczech, Indiach, Japonii, Singapurze, Korei Południowej i Szwajcarii. Przeczytaj naszą dokumentację, aby dowiedzieć się więcej na temat jurysdykcji danych oraz odpowiednich danych dotyczących produktów objętych zakresem. Dodatkowo możesz śledzić nasz harmonogram, aby uzyskać aktualizacje dotyczące jurysdykcji danych, w tym rozszerzenia o nowe produkty, regiony i typy danych.

Kopie zapasowe danych

W Atlassian realizujemy kompleksowy program tworzenia kopii zapasowych. Obejmuje on nasze systemy wewnętrzne, w których mechanizmy tworzenia kopii zapasowych zaprojektowano zgodnie z wymaganiami odzyskiwania systemu. W przypadku produktów chmurowych, a w szczególności danych klientów i aplikacji, dysponujemy również rozbudowanym mechanizmem tworzenia kopii zapasowych. Korzystamy z funkcji migawki usługi relacyjnej bazy danych Amazon RDS (Relational Database Service) w celu codziennego tworzenia zautomatyzowanych kopii zapasowych każdej instancji RDS.

Migawki Amazon RDS są przechowywane przez 30 dni z obsługą odzyskiwania do określonego momentu i są szyfrowane przy użyciu algorytmu AES-256. Dane kopii zapasowych nie są przechowywane na zewnątrz, tylko replikowane do wielu centrów danych w obrębie konkretnego regionu AWS. Co kwartał przeprowadzamy również testowanie naszych kopii zapasowych.

W przypadku Bitbucket migawki magazynu są przechowywane przez 7 dni z obsługą odzyskiwania do określonego momentu.

Nie używamy tych kopii zapasowych do przywracania destrukcyjnych zmian zainicjowanych przez klienta, takich jak pola nadpisane za pomocą skryptów albo usunięte zgłoszenia, projekty lub witryny. W celu uniknięcia utraty danych zalecamy regularne wykonywanie kopii zapasowych. Więcej informacji na temat tworzenia kopii zapasowych można znaleźć w dokumentacji pomocy technicznej danego produktu.

Bezpieczeństwo centrów danych

AWS ma wiele certyfikatów potwierdzających ochronę ich centrów danych. Te certyfikaty dotyczą bezpieczeństwa fizycznego i środowiskowego, dostępności systemu, dostępu do sieci oraz sieci szkieletowej IP, aprowizacji klientów i zarządzania problemami. Dostęp do centrów danych jest ograniczony wyłącznie do upoważnionego personelu i sprawdzany przy użyciu biometrycznych mechanizmów weryfikacji tożsamości. Zabezpieczenia fizyczne obejmują ochronę na terenie firmy, monitoring wizyjny w obwodzie zamkniętym, śluzy oraz dodatkowe środki ochrony przed włamaniem.

Architektura usług rozproszonych

Wykorzystujemy tę architekturę AWS do hostowania wielu usług platformowych i produktowych stosowanych w naszych rozwiązaniach. Dotyczy to funkcji platformy, które są współdzielone i stosowane w wielu produktach Atlassian, takich jak Media, Identity, Commerce, środowisk takich jak nasz edytor, a także możliwości specyficznych dla konkretnego produktu, takich jak usługa zgłoszeń w systemie Jira i analizy Confluence.

Architektura z wielodostępem

Wykorzystując naszą infrastrukturę chmurową, zbudowaliśmy i utrzymujemy wielodostępną architekturę mikrousług ze współdzieloną platformą do obsługi naszych produktów. W architekturze z wielodostępem pojedyncza usługa obsługuje wielu klientów, w tym bazy danych i instancje obliczeniowe wymagane do uruchamiania naszych produktów chmurowych. Każdy shard (zasadniczo kontener — patrz rysunek 3 poniżej) zawiera dane wielu dzierżawców, jednak dane każdego dzierżawcy są odizolowane i niedostępne dla innych dzierżawców. Należy pamiętać, że nie oferujemy architektury z pojedynczym dostępem.

Aprowizacja i cykl życia dzierżaw

Po aprowizacji nowego klienta seria zdarzeń wyzwala orkiestrację usług rozproszonych i aprowizację magazynów danych. Te zdarzenia można zasadniczo przypisać do jednego z siedmiu etapów cyklu życia:

1. Systemy handlowe są niezwłocznie aktualizowane o najnowsze metadane i informacje o kontroli dostępu dla danego klienta, a następnie system orkiestracji aprowizacji dopasowuje „stan aprowizowanych zasobów” do stanu licencji poprzez serię zdarzeń związanych z dzierżawą i produktami.

Zdarzenia dotyczące dzierżawy

Zdarzenia, które wpływają na dzierżawę jako całość, i mogą obejmować:

• Tworzenie: dzierżawa jest tworzona i stosowana do zupełnie nowych witryn.
• Likwidacja: cała dzierżawa jest usuwana.

Zdarzenia dotyczące produktów

• Aktywacja: po aktywacji licencjonowanych produktów lub aplikacji innych firm.
• Dezaktywacja: po dezaktywacji niektórych produktów lub aplikacji.
• Zawieszenie: po zawieszeniu konkretnego istniejącego produktu i tym samym zablokowaniu dostępu do posiadanej witryny.
• Wycofanie zawieszenia: po cofnięciu zawieszenia konkretnego istniejącego produktu i tym samym zapewnieniu dostępu do posiadanej witryny.
• Aktualizacja licencji: zawiera informacje dotyczące liczby stanowisk licencyjnych danego produktu oraz jego statusu (aktywny/ nieaktywny).

2. Utworzenie witryny klienta i aktywacja poprawnego zestawu produktów dla klienta. Zgodnie z koncepcją witryna jest kontenerem wielu produktów licencjonowanych przez konkretnego klienta. (np. Confluence i Jira Software w przypadku witryny ＜site-name＞.atlassian.net).

Oddzielenie dzierżawców

Choć nasi klienci korzystają ze wspólnej infrastruktury chmurowej, stosujemy środki zapewniające logiczną separację klientów, tak aby działania jednego klienta nie wpływały na dane ani usługi innych klientów.

Podejście Atlassian do osiągnięcia takiego stanu zależy od rodzaju naszej aplikacji. W przypadku Jira i Confluence Cloud do logicznego odizolowania naszych klientów wykorzystujemy koncepcję nazywaną „kontekstem dzierżawcy”. Implementujemy ją na poziomie kodu aplikacji i zarządzamy przy użyciu opracowanej przez nas usługi o nazwie „Tenant Context Service” (TCS). Założenia tej koncepcji są następujące:

• Podczas magazynowania dane każdego klienta są logicznie oddzielone od innych dzierżawców.
• Wszelkie wnioski przetwarzane przez Jira lub Confluence mają widok właściwy dla dzierżawcy, co sprawia, że nie ma on wpływu na innych dzierżawców.

Ogólnie rzecz biorąc działanie usługi TCS opiera się na przechowywaniu kontekstu poszczególnych dzierżawców klienta. Kontekst każdego dzierżawcy jest powiązany z unikatowym identyfikatorem przechowywanym centralnie przez usługę TCS i obejmuje szereg metadanych skojarzonych z dzierżawcą, takich jak bazy danych, w których znajduje się dzierżawca; licencje posiadane przez dzierżawcę; funkcje, do których ma on dostęp oraz szereg innych informacji na temat konfiguracji. Gdy klient uzyskuje dostęp do Jira lub Confluence Cloud, usługa TCS używa identyfikatora dzierżawcy, aby zebrać te metadane, które następnie są łączone z dowolnymi operacjami podejmowanymi przez dzierżawcę w aplikacji w trakcie całej sesji.

Granice Atlassian

Twoje dane są również zabezpieczone za pomocą czegoś, co nazywamy granicą — wirtualnymi ścianami wybudowanymi wokół naszego oprogramowania. Przychodzące żądanie jest wysyłane do najbliższej granicy. Po wykonaniu szeregu walidacji żądanie jest dopuszczane lub odrzucane.

• Żądanie trafia do granicy Atlassian najbliższej użytkownikowi. Krawędź weryfikuje sesję i tożsamość użytkownika za pośrednictwem jego systemu zarządzania tożsamościami.
• Następnie w oparciu o dane zawarte w informacjach usługi TCS granica ustala lokalizację danych produktu klienta.
• Granica przekazuje żądanie do regionu docelowego, gdzie trafia ono do węzła obliczeniowego.
• Węzeł wykorzystuje system konfiguracji dzierżawców do ustalenia informacji, takich jak lokalizacja bazy danych i licencji, a następnie wywołuje różne inne magazyny danych i usługi (np. platformę multimedialną pełniącą funkcję hosta dla obrazów i załączników) w celu pobrania informacji wymaganych do obsługi żądania.
• Pierwotne żądanie użytkownika zawierające informacje zebrane na podstawie jego poprzednich wywołań do innych usług.

Uwierzytelnianie i autoryzacja usług

Nasza platforma wykorzystuje model dostępu do danych oparty na najniższym poziomie uprawnień. To oznacza, że dostęp do wszystkich danych jest ograniczony wyłącznie do usług odpowiadających za ich zapisywanie, przetwarzanie lub pobieranie. Przykładowo usługi multimedialne zapewniające jednolite środowisko przekazywania i pobierania plików w naszych produktach chmurowych mają dedykowany magazyn, do którego nie mają dostępu żadne inne usługi Atlassian. Każda usługa wymagająca dostępu do treści multimedialnych musi wejść w interakcję z interfejsem API usług multimedialnych. W rezultacie silne uwierzytelnianie i autoryzacja w warstwie usług wymuszają również wyraźny podział obowiązków i dostęp z najniższym poziomem uprawnień do danych.

Wykorzystujemy tokeny internetowe JSON (JWT) w celu zapewnienia urzędu podpisywania poza aplikacją, dzięki czemu nasze systemy zarządzania tożsamościami i kontekst dzierżawcy zawierają rzetelne dane. Tokenów nie da się użyć w żadnym innym celu poza tym, do którego zostały autoryzowane. Gdy użytkownik lub dowolny członek jego zespołu wywoła mikrousługę lub shard, tokeny zostaną przekazane do jego systemu zarządzania tożsamościami i zweryfikowane. Taki proces pozwala zyskać pewność, że token jest aktualny i podpisany, zanim udostępni się odpowiednie dane. W połączeniu z autoryzacją i uwierzytelnianiem wymaganymi w celu uzyskania dostępu do tych mikrousług ewentualne naruszenie zabezpieczeń usługi ma ograniczone skutki.

Wiemy jednak, że czasami może dojść do naruszenia zabezpieczeń systemów zarządzania tożsamościami. W celu ograniczania takiego ryzyka wykorzystujemy dwa mechanizmy. Przede wszystkim stawiamy na dużą replikację usług TCS i serwerów proxy zarządzania tożsamościami. Niemal każda mikrousługa ma rezerwową usługę TCS, a dodatkowo wykorzystujemy rezerwowe serwery proxy, które odsyłają do urzędu tożsamości, skutkiem czego przez cały czas działają tysiące takich usług. Jeśli w obrębie dowolnej ich liczby zostanie wykryte nieprawidłowe działanie, możemy to szybko wychwycić i naprawić problem.

Ponadto nie czekamy, aż ktoś znajdzie lukę w zabezpieczeniach naszych produktów lub naszej platformy. Aktywnie identyfikujemy takie scenariusze, aby ograniczyć do minimum ich skutki dla Ciebie, a ponadto prowadzimy szereg programów zapewniania bezpieczeństwa w celu identyfikowania i wykrywania zagrożeń oraz reagowania na nie.

Usługa TCS

Upewniamy się, że żądania wysyłane do dowolnych mikrousług zawierają metadane dotyczące klienta lub dzierżawcy żądającego dostępu. Taka usługa jest nazywana TCS (Tenant Context Service). Wprowadzane do niej dane pochodzą bezpośrednio z naszych systemów aprowizacji. Po uruchomieniu żądania następuje odczytanie kontekstu, który następnie jest umieszczany w kodzie działającej usługi używanej do autoryzacji użytkownika. Dostęp do wszystkich usług, a tym samym do danych, w produktach Jira i Confluence wymaga takiego kontekstu dzierżawcy, gdyż w przeciwnym razie żądanie zostanie odrzucone.

Do autoryzacji i uwierzytelniania usług wykorzystywany jest protokół uwierzytelniania usług Atlassian (ASAP, Atlassian Service Authentication Protocol). Na podstawie jawnej listy dozwolonych usług jest określane, które usługi mogą nawiązywać komunikację, a szczegóły autoryzacji decydują o dostępnych poleceniach i ścieżkach. To ogranicza potencjalny ruch boczny w ramach usługi, której bezpieczeństwo zostało naruszone.

Procesy autoryzacji i uwierzytelniania usług, a także ruch wychodzący, podlegają kontroli za pomocą zbioru dedykowanych serwerów proxy. Dzięki temu luki w zabezpieczeniach kodu aplikacji nie wpływają na te środki kontroli. Zdalne wykonanie kodu wymagałoby naruszenia hosta bazowego i obejścia granic kontenera Docker, a nie jedynie zmodyfikowania logiki aplikacji, ponieważ system wykrywania nieautoryzowanego dostępu na poziomie hosta sygnalizowałby rozbieżności.

Te serwery ograniczają ruch wychodzący w oparciu o zamierzone zachowania usługi. Usługom, które nie muszą wysyłać elementów webhook lub komunikować się z innymi mikrousługami, nie wolno tego robić.

Szyfrowanie danych

Customer data in Atlassian cloud products is encrypted during transmission utilizing TLS 1.2 or higher, incorporating perfect forward secrecy (PFS) to safeguard against unauthorized information disclosure and data modification. We adhere to NIST-recommended TLS 1.2+ protocols, which enforce the use of strong ciphers and key lengths as supported by the browser.

Customer data, including attachments, stored on the cloud services such as Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie, and Trello are protected using industry-standard AES-256 encryption at rest.

Personally Identifiable Information (PII) transmission is protected through encryption and robust data access controls, which are designed to ensure that data is securely transmitted to its intended destination. Atlassian's Cryptography and Encryption Policy outlines principles for implementing encryption and cryptography to mitigate risks related to storing and transmitting PII. The encryption algorithms for protecting PII are aligned with the classification level of the PII, as specified by Atlassian's internal Data Security & Information Lifecycle Management policies. This ensures that sensitive data is adequately secured based on its classification. To learn more about how we collect, share, and use customer data, refer to our privacy page.

Aktualne informacje na temat dodatkowych możliwości szyfrowania danych można znaleźć w naszym planie rozwoju wersji Cloud.