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

We operate a comprehensive backup program at Atlassian. This includes our internal systems, where our backup measures are designed in line with system recovery requirements. With respect to our cloud apps, and specifically referring to you and your application data, we also have extensive backup measures in place. We use the snapshot feature of Amazon RDS (Relational database service) to create automated daily backups of each RDS instance.

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.

We don’t use these backups to revert customer-initiated destructive changes, such as fields overwritten using scripts, or deleted work items, projects, or sites. To avoid data loss, we recommend making regular backups. Learn more about creating backups in the support documentation for your product.

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

With this AWS architecture, we host a number of platform and product services that are used across our solutions. This includes platform capabilities that are shared and consumed across multiple Atlassian products, such as Media, Identity, and Commerce, experiences such as our Editor, and product-specific capabilities, like Jira Work Item service and Confluence Analytics.

Architektura z wielodostępem

On top of our cloud infrastructure, we built and operate a multi-tenant micro-service architecture along with a shared platform that supports our products. In a multi-tenant architecture, a single service serves multiple customers, including databases and compute instances required to run our cloud apps. Each shard (essentially a container – see figure 3 below) contains the data for multiple tenants, but each tenant's data is isolated and inaccessible to other tenants. It is important to note that we do not offer a single tenant architecture.

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

While our customers share a common cloud-based infrastructure when using our cloud apps, we have measures in place to ensure they are logically separated so that the actions of one customer cannot compromise the data or service of other customers.

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

Our platform uses a least privilege model for accessing data. This means that all data is restricted to only the service responsible for saving, processing, or retrieving it. For example, the media services, which allows you to have a consistent file upload and download experience across our cloud apps, have dedicated storage provisioned that no other services at Atlassian can access. Any service that requires access to the media content needs to interact with the media services API. As a result, strong authentication and authorization at the service layer also enforces strong separation of duties and least privilege access to data.

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 apps 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.

Dane klientów, w tym załączniki, przechowywane w usługach chmurowych, takich jak Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie i Trello, są chronione za pomocą standardowego szyfrowania AES-256 w trakcie magazynowania.

Przekazywanie danych osobowych (PII) jest chroniona za pomocą szyfrowania i solidnych kontroli dostępu do danych, które mają na celu zapewnienie bezpiecznego przesyłania danych do zamierzonego miejsca docelowego. Polityka kryptografii i szyfrowania firmy Atlassian określa zasady wdrażania szyfrowania i kryptografii w celu zmniejszenia ryzyka związanego z przechowywaniem i przesyłaniem danych osobowych. Algorytmy szyfrowania służące do ochrony danych osobowych są dostosowane do poziomu klasyfikacji danych osobowych, zgodnie z wewnętrznymi zasadami zarządzania cyklem życia informacji firmy Atlassian Data Security &. Zapewnia to, że dane wrażliwe są odpowiednio zabezpieczone na podstawie ich klasyfikacji. Więcej informacji na temat sposobu, w jaki zbieramy, udostępniamy i wykorzystujemy dane klientów, można znaleźć na naszej stronie dotyczącej ochrony prywatności.

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