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. Zdajemy sobie jednak sprawę, że niektórzy mogą wymagać, aby dane znajdowały się w konkretnej lokalizacji, dlatego zapewniamy funkcję jurysdykcji danych. Obecnie oferujemy jurysdykcję danych w USA i UE, a także w Australii, a ponadto planujemy dodanie kolejnych regionów. Więcej informacji można znaleźć na naszej stronie dotyczącej jurysdykcji danych, gdzie można również zasubskrybować powiadomienia o aktualnościach.

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

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.

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

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

Dane klientów przechowywane w produktach Atlassian Cloud są szyfrowane w trakcie przesyłania przez sieci publiczne przy użyciu protokołu TLS 1.2+ z doskonałym utajnianiem przekazywania (PFS) w celu ochrony przed nieupoważnionym ujawnieniem lub modyfikacją. Nasza implementacja protokołu TLS wymusza stosowanie silnych szyfrów i odpowiednich długości kluczy, jeśli są obsługiwane przez przeglądarkę.

Dyski serwerowe, na których przechowywane są dane i załączniki klientów korzystających z produktów Jira Cloud, Jira Service Management Cloud, Bitbucket Cloud, Confluence Cloud, Jira Product Discovery, Statuspage, Opsgenie i Trello, są w całości szyfrowane podczas magazynowania przy użyciu metody AES-256, będącej standardem w branży.

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.

Zarządzanie kluczami

Do zarządzania kluczami Atlassian wykorzystuje usługę zarządzania kluczami AWS Key Management Service (KMS). W celu dodatkowej ochrony prywatności tych danych KMS pełni funkcję twórcy i magazynu tajnego tych kluczy. Kontrolę i weryfikację szyfrowania, deszyfrowania oraz zarządzania kluczami przeprowadza wewnętrznie AWS w regularnych odstępach czasu, w ramach własnych wewnętrznych procesów sprawdzania poprawności. Do każdego klucza jest przydzielony właściciel odpowiedzialny za zapewnienie stosowania odpowiedniego poziomu kontroli zabezpieczeń w przypadku kluczy. W przypadku istotnych zmian ról lub statusu zatrudnienia następuje rotacja kluczy zarządzanych przez Atlassian.

Wykorzystujemy również szyfrowanie przy użyciu techniki Envelope. AWS posiada klucz główny, do którego nigdy nie mamy dostępu, a każde żądanie szyfrowania lub odszyfrowania klucza wymaga właściwych ról i uprawnień AWS. Stosując szyfrowanie przy użyciu techniki Envelope do tworzenia lub generowania kluczy dla poszczególnych klientów, uzyskujemy różne zestawy kluczy danych dla odmiennych rodzajów danych w naszych magazynach danych. Ponadto nasze podejście do szyfrowania na poziomie wewnętrznej warstwy aplikacji zakłada posiadanie zapasowych kluczy danych w innych regionach AWS. Rotacja kluczy odbywa się automatycznie w cyklach rocznych i nie używa się tego samego klucza danych w przypadku ponad 100 000 elementów danych.

Wkrótce będziemy również oferowali szyfrowanie typu Bring Your Own Key (BYOK), dzięki czemu zyskasz możliwość szyfrowania danych produktów chmurowych przy użyciu samodzielnie zarządzanych kluczy w usłudze AWS KMS. Szyfrowanie BYOK zapewni pełną kontrolę nad zarządzaniem kluczami i w dowolnej chwili będzie można przyznać lub odwołać dostęp, zarówno dla swoich użytkowników końcowych, jak i systemów Atlassian.

Usługę AWS KMS można zintegrować z AWS CloudTrail na koncie AWS, aby uzyskać dzienniki z informacjami o użyciu wszystkich kluczy. Takie rozwiązanie umożliwia szyfrowanie danych na różnych warstwach aplikacji, takich jak bazy danych, magazyny plików, a także nasze wewnętrzne pamięci podręczne i kolejki zdarzeń. Na żadnym etapie procesu nie ma to negatywnego wpływu na możliwość korzystania z produktu.