ENISA: Agencja Unii Europejskiej ds. Cyberbezpieczeństwa

Agencja Unii Europejskiej ds. Cyberbezpieczeństwa (ENISA) stanowi centrum wiedzy na temat sieci i środowiska informatycznego. Ściśle współpracuje z państwami członkowskimi UE i sektorem prywatnym, opracowując porady i zalecenia dotyczące dobrych praktyk w zakresie cyberbezpieczeństwa. ENISA pomaga również w opracowywaniu i wdrażaniu zasad i przepisów UE związanych z krajowym cyberbezpieczeństwem.

Raport Cloud Computing Information Assurance Framework (IAF) ENISA jest zbiorem kryteriów dotyczących zapewnienia bezpieczeństwa, które organizacje mogą wykorzystać do oceny dostawców usług chmurowych (CSP), aby zyskać pewność, że stosują oni właściwe środki ochrony danych ich klientów. IAF ma na celu ocenę ryzyka wdrożenia chmury i zmniejszenie obciążenia dostawców usług chmurowych obowiązkami związanymi z systemem bezpieczeństwa.

Firma Atlassian spełnia wymagania stawiane przez IAF poprzez zgodność z modelem Cloud Control Matrix (CCM) opracowanym przez Cloud Security Alliance (CSA), który mapuje domeny i środki kontroli CCM na kryteria zapewniania bezpieczeństwa IAF, a także poprzez uzyskanie certyfikatu ISO 27001.

Firma Atlassian prowadzi następujące programy zapewniania bezpieczeństwa bazujące na CCM:

• Samoocena CSA Star 1

Poniższe wytyczne zawierają kryteria zapewnienia bezpieczeństwa, które ułatwią organizacjom wybór dostawcy usług chmurowych. Wszelkie pytania dotyczące konkretnych zagadnień szczegółowych prosimy kierować do naszego zespołu sprzedaży produktów Enterprise za pośrednictwem strony https://www.atlassian.com/enterprise/contact?formType=product-features.

6.01

Większość pytań dotyczących personelu będzie podobna do tych, które zadałoby się własnym pracownikom działu IT lub innym członkom personelu zajmującym się zagadnieniami IT. Podobnie jak w przypadku większości ocen zachowano równowagę między ryzykiem a kosztami.

6.01. (a)

Jakie zasady i procedury stosujesz przy zatrudnianiu administratorów IT lub innych osób z dostępem do systemu? Powinny one obejmować:

• Kontrole przed zatrudnieniem (tożsamość, narodowość lub status, historia zatrudnienia i referencje, zaświadczenie o niekaralności i weryfikacja (w przypadku pracowników wyższego szczebla, których rola wiąże się z szerokim zakresem uprawnień)).

Zgodnie z przepisami obowiązującymi w miejscu zamieszkania nowych pracowników Atlassian są oni zobowiązani do poddania się pełnemu sprawdzeniu przeszłości. Zgodnie z przepisami obowiązującymi w miejscu zamieszkania nowo zatrudnionych pracowników, pracownicy ci będą poddawani sprawdzeniu przeszłości już po dacie zatrudnienia. Wszyscy nowi pracownicy i niezależni wykonawcy przechodzą sprawdzenie pod kątem karalności, sprawdza się również ich wykształcenie, historię zatrudnienia oraz sytuację kredytową, jeśli rola lub stanowisko tego wymagają. Kierownictwo wyższego szczebla oraz księgowi przechodzą pełne sprawdzenie przeszłości.

6.01. b)

Czy stosuje się odmienne zasady w zależności od miejsca przechowywania danych lub uruchamiania aplikacji?

• Przykładowo zasady zatrudniania w jednym regionie mogą różnić się od zasad zatrudnienia w innym regionie.
• Praktyki muszą być spójne we wszystkich regionach.
• Może się zdarzyć, że dane wrażliwe będą przechowywane w jednym konkretnym regionie obsługiwanym przez odpowiedni personel.

Firma Atlassian nakłada ograniczenia na personel, który potrzebuje dostępu do naszych systemów, aplikacji oraz infrastruktury, zgodnie z pełnioną funkcją i zakresem obowiązków, stosując zasadę minimalnych wymaganych uprawnień, co uzyskujemy dzięki naszym procesom uwierzytelniania. Cały dostęp odbywa się za pośrednictwem uwierzytelnionych sesji i w oparciu o konkretne uprawnienia.

Wszystkie systemy warstwy 1 są zarządzane za pośrednictwem scentralizowanej usługi logowania jednokrotnego (SSO) oraz katalogu Atlassian. Użytkownicy otrzymują odpowiednie prawa dostępu w oparciu o te profile, sterowane za pomocą przepływu pracy z naszego systemu zarządzania HR. W przypadku dostępu do wszystkich systemów warstwy 1 firma Atlassian stosuje uwierzytelnianie wieloskładnikowe. Włączyliśmy usługę uwierzytelniania dwuskładnikowego w konsoli zarządzania usługą hipernadzorcy oraz w interfejsie API AWS, a także codzienny raport z audytu na temat wszystkich prób uzyskania dostępu do funkcji zarządzania usługą hipernadzorcy. Listy dostępu do konsoli zarządzania usługą hipernadzorcy oraz interfejsu API AWS są przeglądane co kwartał. Co 8 godzin przeprowadzamy również synchronizację naszego systemu HR i magazynu tożsamości.

Środki kontroli związane z kontrolą dostępu zostały szerzej omówione w Zasadach zarządzania uprawnieniami dostępu, których fragment można znaleźć na stronie: https://www.atlassian.com/trust

6.01. (c)

Jak funkcjonuje program szkoleniowy w zakresie bezpieczeństwa obejmujący wszystkich pracowników?

Atlassian zapewnia szkolenia z zakresu bezpieczeństwa informatycznego jako element szkolenia onboardingowego („Dzień 1”) dla nowych pracowników, a także ich ciągłość dla wszystkich pracowników.

Oprócz tego ogólnego szkolenia dotyczącego bezpieczeństwa informatycznego, nasi programiści przechodzą bardziej specjalistyczne szkolenie na temat bezpiecznego tworzenia kodu wspierane przez nasz zintegrowany program prowadzony przez inżynierów bezpieczeństwa.

Prowadzimy również ciągłe szkolenia tematyczne na temat złośliwego oprogramowania, phishingu oraz innych zagadnień związanych z bezpieczeństwem. Więcej informacji można znaleźć na stronie: https://www.atlassian.com/trust/security/security-practices#security-awareness-training

Prowadzimy formalną dokumentację ukończenia wewnętrznego szkolenia personelu. Pracownicy są zobowiązani do zaakceptowania Kodeksu postępowania i potwierdzania swojej zgody co roku. Zasady te są dostępne dla wszystkich pracowników. Wymogi dotyczące świadomości bezpieczeństwa, poufności i prywatności są prezentowane podczas szkoleń pierwszego dnia i są dostępne dla wszystkich pracowników w Confluence.

6.01. (d)

Czy stosowany jest proces ciągłej ewaluacji?

• Jak często się ją przeprowadza?
• Dodatkowe rozmowy.
• Przeglądy uprawnień i dostępu do zabezpieczonych danych.
• Przeglądy zasad i procedur.

Firma Atlassian uzyskała certyfikaty SOC2, ISO27001 i ISO27018 dla oferowanych usług chmurowych. Przeprowadzamy audyty wewnętrzne oraz audyty gotowości i audyty zewnętrzne co najmniej raz w roku. Atlassian ma certyfikat ISO dla wielu produktów, co wymaga regularnych ocen ryzyka i przeglądów praktyk dotyczących danych.

Więcej informacji można znaleźć na stronie: https://www.atlassian.com/trust/compliance. Klienci powinni regularnie pobierać i przeglądać aktualizacje naszych certyfikatów zgodności i raportów z tej witryny.

W firmie Atlassian obowiązuje udokumentowany zbiór zasad, wśród których najważniejsze są Zasady dotyczące bezpieczeństwa. Zdefiniowaliśmy również Policy Management Program (PMP), który obejmuje obowiązki związane z własnością, dostępnością i cyklem weryfikacji oraz określa nasze ogólne cele. Nasze zasady są sprawdzane co najmniej raz w roku i zatwierdzane przez kierownictwo wyższego szczebla. Więcej informacji na temat naszego PMP można znaleźć pod adresem: https://www.atlassian.com/trust/security/security-management-program

Opublikowaliśmy również fragmenty z poszczególnych zasad ogólnych w wersji skróconej, które można znaleźć pod adresem: https://www.atlassian.com/trust/security/ismp-policies

Wszystkie systemy i projekty podlegają ocenie skutków, ponieważ są one związane z informacjami umożliwiającymi identyfikację osoby.

Umowy firmy Atlassian z podmiotami zewnętrznymi zawierają w stosownych przypadkach zapisy dotyczące bezpieczeństwa i ochrony prywatności. Nowi dostawcy Atlassian są zobowiązani do wyrażenia zgody na zasady ochrony prywatności i bezpieczeństwa zawarte w naszych umowach. Nasze zespoły prawne i zakupowe sprawdzają umowy, umowy SLA i wewnętrzne zasady dostawców, aby zarządzać ryzykiem związanym z bezpieczeństwem, dostępnością i poufnością. W ramach zarządzania ryzykiem w firmie (ERM) Atlassian przeprowadza coroczną ocenę ryzyka, która uwzględnia prawdopodobieństwo i potencjalne skutki wszystkich kategorii ryzyka i jest zgodna z modelem ryzyka COSO. W razie potrzeby przeprowadzamy również oceny ryzyka funkcjonalnego w oparciu o profil ryzyka. Ocena ryzyka podlega ponownej analizie w ramach odnowienia zasad oraz przy każdej istotnej zmianie relacji z dostawcą.

6.02.

Poniższe pytania mają zastosowanie w przypadku, gdy dostawca chmury podzleca niektóre kluczowe dla bezpieczeństwa operacje stronom trzecim (np. dostawca SaaS zlecający zewnętrznemu dostawcy obsługę platformy bazowej, dostawca usług w chmurze zlecający dostawcy zarządzanych usług bezpieczeństwa obsługę zabezpieczeń, korzystanie z usług zewnętrznego dostawcy w zakresie zarządzania tożsamością systemów operacyjnych itp.). Obejmuje to również strony trzecie z fizycznym lub zdalnym dostępem do infrastruktury dostawcy chmury. Zakłada się, że cały kwestionariusz może być stosowany rekurencyjnie do zewnętrznych dostawców usług w chmurze.

6.02. (a)

Proszę zdefiniować usługi w łańcuchu dostaw o kluczowym znaczeniu dla bezpieczeństwa (w tym dostępności) operacji, które są zlecane na zasadzie outsourcingu lub podwykonawstwa.

Atlassian współpracuje z zewnętrznymi podwykonawcami przy dostarczaniu witryn internetowych, tworzeniu aplikacji, hostingu, konserwacji, tworzeniu kopii zapasowych, przechowywaniu danych, infrastrukturze wirtualnej, przetwarzaniu płatności, analizie i innych usługach. Lista podrzędnych podmiotów przetwarzających aktualnie zaangażowanych przez Atlassian i upoważnionych przez Klienta znajduje się na stronie https://www.atlassian.com/legal/sub-processors.

6.02. (b)

Proszę przedstawić szczegółowo procedury stosowane w celu zapewnienia podmiotom zewnętrznym dostępu do infrastruktury (fizycznej i/lub logicznej).

• Czy i jak często przeprowadzacie audyty podwykonawców?

Nasze zespoły prawne i zakupowe sprawdzają umowy, w tym SLA, oraz wewnętrzne zasady dostawców, aby zarządzać ryzykiem związanym z bezpieczeństwem, dostępnością i poufnością. W razie potrzeby przeprowadzamy również oceny ryzyka funkcjonalnego w oparciu o profil ryzyka. Ocena ryzyka podlega ponownej analizie w ramach odnowienia zasad oraz przy każdej istotnej zmianie relacji z dostawcą. Nasze zasady dotyczące zarządzania danymi dostawców i stron trzecich obejmują ten proces; ich fragment jest dostępny tutaj: https://www.atlassian.com/trust/security/ismp-policies.

6.02. (c)

Czy jakiekolwiek postanowienia umów SLA gwarantowane przez firmy outsourcingowe są niższe niż te, które oferujecie swoim klientom? Jeśli nie, to czy zapewniona jest nadmiarowość w zakresie dostawców?

W zależności od umowy licencyjnej nasze warunki korzystania z usług chmurowych należy przejrzeć przy odnowieniu subskrypcji miesięcznej lub rocznej. Nasze zespoły prawne i zakupowe sprawdzają umowy, w tym SLA, oraz wewnętrzne zasady dostawców, aby zarządzać ryzykiem związanym z bezpieczeństwem, dostępnością i poufnością. W ramach programu zarządzania ryzykiem korporacyjnym (ERM) stosowanego przez firmę Atlassian przeprowadzana jest coroczna ocena ryzyka, która uwzględnia prawdopodobieństwo i potencjalne skutki wszystkich kategorii ryzyka oraz jest zgodna z modelem ryzyka COSO. W razie potrzeby przeprowadzamy również oceny ryzyka funkcjonalnego w oparciu o profil ryzyka. Ocena ryzyka podlega ponownej analizie w ramach odnowienia zasad oraz przy każdej istotnej zmianie relacji z dostawcą.

6.02. (d)

Jakie środki są podejmowane w celu zapewnienia przestrzegania i utrzymania poziomów usług stron trzecich?

Nasze zespoły prawne i zakupowe sprawdzają umowy, w tym SLA, oraz wewnętrzne zasady dostawców, aby zarządzać ryzykiem związanym z bezpieczeństwem, dostępnością i poufnością. W razie potrzeby przeprowadzamy również oceny ryzyka funkcjonalnego w oparciu o profil ryzyka. Ocena ryzyka podlega ponownej analizie w ramach odnowienia zasad oraz przy każdej istotnej zmianie relacji z dostawcą. Nasze zasady dotyczące zarządzania danymi dostawców i stron trzecich obejmują ten proces; ich fragment jest dostępny tutaj: https://www.atlassian.com/trust/security/ismp-policies.

6.02. (e)

Czy dostawca chmury może potwierdzić, że zasady bezpieczeństwa i mechanizmy kontroli są stosowane (zgodnie z umową) wobec jego dostawców zewnętrznych?

Wszystkie systemy i projekty są poddawane ocenie skutków w odniesieniu do danych osobowych. Umowy firmy Atlassian ze stronami trzecimi zawierają w stosownych przypadkach zapisy dotyczące bezpieczeństwa i ochrony prywatności. Nowi dostawcy Atlassian są zobowiązani do wyrażenia zgody na zasady ochrony prywatności i bezpieczeństwa zawarte w naszych umowach.

Nasze zespoły prawne i zakupowe sprawdzają umowy, w tym SLA, oraz wewnętrzne zasady dostawców, aby zarządzać ryzykiem związanym z bezpieczeństwem, dostępnością i poufnością. W ramach programu zarządzania ryzykiem korporacyjnym (ERM) stosowanego przez firmę Atlassian przeprowadzana jest coroczna ocena ryzyka, która uwzględnia prawdopodobieństwo i potencjalne skutki wszystkich kategorii ryzyka oraz jest zgodna z modelem ryzyka COSO. W razie potrzeby przeprowadzamy również oceny ryzyka funkcjonalnego w oparciu o profil ryzyka. Ocena ryzyka podlega ponownej analizie w ramach odnowienia zasad oraz przy każdej istotnej zmianie relacji z dostawcą.

6.03.

Oczekuje się, że wszelkie umowy handlowe z dostawcami zewnętrznymi będą obejmować poziomy świadczenia wszystkich usług sieciowych. Jednak niezależnie od zdefiniowanej umowy klient końcowy powinien upewnić się, że dostawca stosuje odpowiednie środki kontroli w celu ograniczenia nieuprawnionego ujawniania informacji.

6.03. (a)

Proszę przedstawić szczegółowo procedurę i zasady kontroli zmian, uwzględniając proces wykorzystywany do ponownej oceny ryzyka w następstwie zmian, i wyjaśnić, czy wyniki są dostępne dla klientów końcowych.

Atlassian prowadzi program zarządzania ryzykiem korporacyjnym (ERM) zgodny z modelem ryzyka COSO oraz normą ISO 31000. W ramach programu ERM w firmie Atlassian są wdrażane ramy postępowania i metody zarządzania ryzykiem, a także przeprowadzane są doroczne oceny ryzyka, okresowe oceny konkretnych rodzajów ryzyka w środowisku produktu oraz doraźnie, funkcjonalne oceny ryzyka (w zależności od jego profilu).

Ramy postępowania zarządzania ryzykiem w firmie Atlassian obejmują w szczególności normy, procesy, role i obowiązki, dopuszczalne tolerancje ryzyka oraz dyrektywy dotyczące wykonywania czynności związanych z oceną ryzyka. Nasz proces i nasze praktyki zarządzania ryzykiem określają sposób realizacji naszych ocen ryzyka, które są powtarzalne i pozwalają uzyskać prawidłowe, spójne i porównywalne wyniki. Oceny ryzyka przeprowadzane przez firmę Atlassian uwzględniają prawdopodobieństwo wystąpienia oraz wpływ w obrębie wszystkich kategorii ryzyka, a także sposób podejścia do wszelkich form ryzyka zgodny z naszym wewnętrznym poziomem tolerancji ryzyka. Na każdym etapie programu ERM zespół ds. ryzyka i zapewniania zgodności z przepisami informuje odpowiednich interesariuszy i konsultuje się z właściwymi ekspertami.

Personel uczestniczący w procesach zarządzania ryzykiem w firmie Atlassian jest wystarczająco świadomy i przeszkolony w zakresie swoich obowiązków i ich wykonywania. Wszystkie ryzyka są śledzone i zarządzane za pomocą naszego własnego narzędzia Jira, z odpowiedzialnością na poziomie kierownictwa oraz powiązanymi planami i projektami naprawczymi. Więcej informacji można znaleźć na stronie: https://www.atlassian.com/trust/security/security-management-program lub https://www.atlassian.com/trust/compliance/risk-management-program.

Proces zarządzania zmianami stosowany przez Atlassian różni się nieco od tradycyjnych procesów zmian. W przypadku wszystkich zmian — niezależnie od tego, czy chodzi o zmiany w kodzie, aplikacjach czy infrastrukturze — polegamy na kontroli Peer Review and Green Build (PRGB). Proces Peer Review jest skonfigurowany w naszym narzędziu CD. W jego ramach należy wyznaczyć krytyczne gałęzie, aby mieć wielu recenzentów dla każdego pull requesta. Zazwyczaj jest to dwóch programistów i lider zespołu. Natomiast w ramach procesu Green Build integracja w fazie CI musi przejść pomyślnie wszystkie opracowane testy, m.in. integracyjne, funkcjonalne i bezpieczeństwa. Jeśli testy te zakończą się niepowodzeniem (Red Build), kod nie zostanie scalony i należy go ponownie sprawdzić oraz usunąć błędy. Po pomyślnym przeprowadzeniu procesu Green Build plik binarny jest podpisywany kryptograficznie, a w naszym środowisku produkcyjnym uruchamiane są wyłącznie pliki binarne podpisane naszym kluczem. Nasz proces testowania obejmuje zarówno zautomatyzowane, jak i ręczne elementy oceny. Uwielbiamy blogować o tym, co robimy dobrze. Nasze podejście do stosowania „wspomagania jakości” (w odróżnieniu od tradycyjnego „zapewniania jakości”) jest naszą wielką pasją: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance.

6.03. (b)

Proszę zdefiniować zasady dostępu zdalnego.

Wymagania dotyczące dostępu zdalnego są określone w zasadach zarządzania uprawnieniami dostępu i powiązanych normach. Dane klientów mogą być replikowane na stacjach roboczych pracowników do celów wsparcia lub migracji oraz z aktywnym zgłoszeniem do działu wsparcia. Stosowane są rygorystyczne reguły zapory, co ogranicza dostęp do środowiska produkcyjnego wyłącznie do naszej sieci VPN i autoryzowanych systemów. Dostęp do naszej sieci VPN wymaga uwierzytelniania wieloskładnikowego.

Wszystkie urządzenia (należące do Atlassian lub stosowane w modelu BYOD) używane przez pracowników firmy Atlassian, które mogą mieć dostęp do DOWOLNYCH narzędzi Atlassian, są rejestrowane w systemie zarządzania urządzeniami przy użyciu profili bezpieczeństwa oprogramowania MDM i funkcji sprawdzania stanu zabezpieczeń. Atlassian stosuje model bezpieczeństwa Zero Trust w odniesieniu do wszystkich urządzeń Atlassian. Więcej informacji można znaleźć tutaj: https://www.atlassian.com/trust/compliance/resources/eba/eba-guidance.

6.03. (c)

Czy dostawca utrzymuje udokumentowane procedury operacyjne dotyczące systemów informatycznych?

Podstawowe zasady bezpieczeństwa operacji Atlassian obejmują opracowywanie standardowych dokumentów dotyczących procedur operacyjnych. Opublikowaliśmy również fragmenty z poszczególnych zasad ogólnych w wersji skróconej, które można znaleźć pod adresem: https://www.atlassian.com/trust/security/ismp-policies.

6.03. (d)

Czy istnieją środowiska przejściowe pozwalające ograniczyć ryzyko (np. środowiska programistyczne, testowe i operacyjne) oraz czy są one od siebie oddzielone?

W firmie Atlassian obowiązują zasady bezpieczeństwa informacji zabraniające wykorzystywania danych produkcyjnych w środowiskach nieprodukcyjnych, a wszelkie próby migracji danych między środowiskami są identyfikowane w ramach procesu zarządzania zmianami. Kod jest najpierw przenoszony ze scentralizowanego systemu kompilacji (w ramach tego procesu przeprowadzane są testy jednostkowe). Następnie przechodzi do etapu walidacji gałęzi funkcji obejmującego dodatkową automatyzację testów i przeglądy dokonywane przez kierowników projektów, programistów i specjalistów ds. QA. Kolejny etap to testowanie akceptacyjne przez użytkowników oraz ocena bezpieczeństwa i wydajności. Programiści nie mogą bezpośrednio promować kodu do wersji produkcyjnej. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/security/security-practices#managing-changes-in-our-environment.

Zachowujemy logiczną i fizyczną separację środowisk produkcyjnych i nieprodukcyjnych (używanych do tworzenie oprogramowania) w przypadku wszystkich środowisk i metod stosowanych do ich izolowania.

Nasze środowisko stagingowe jest logicznie (ale nie fizycznie) oddzielone i zarządzane z zastosowaniem procesów dostępu i kontrolowania zmian klasy produkcyjnej. Więcej informacji na temat naszych praktyk w zakresie bezpieczeństwa kodu można znaleźć na stronie: https://www.atlassian.com/trust/security/security-in-development.

6.03. (e)

Proszę zdefiniować mechanizmy kontroli hosta i sieci stosowane w celu ochrony systemów hostujących aplikacje i informacje dla klienta końcowego. Powinny one obejmować szczegółowe informacje na temat certyfikacji zgodności z normami zewnętrznymi (np. ISO 27001/2).

Dział inżynierii sieci firmy Atlassian wykorzystuje technologie IPS wbudowane w naszą chmurę oraz biurowe zapory, a ponadto wdrożyliśmy w naszych środowiskach biurowych technologie IDS. Ochrona przed zagrożeniami sieciowymi jest realizowana przez AWS, co obejmuje ochronę przed atakami DDoS oraz stosowanie określonych funkcji zapór aplikacji internetowych. Wszystkie dane dotyczące naszych usług są szyfrowane w trakcie przesyłania przy użyciu protokołu TLS, aby chronić je przed nieuprawnionym ujawnieniem lub modyfikacją, zarówno w przypadku protokołu HTTPS, jak i SMTPS.

Firma Atlassian uzyskała certyfikaty SOC2, ISO27001 i ISO27018 dla oferowanych usług chmurowych. Przeprowadzamy audyty wewnętrzne, audyty gotowości i audyty zewnętrzne co najmniej raz w roku.

Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/compliance. Klienci powinni regularnie pobierać i przeglądać aktualizacje naszych certyfikatów zgodności i raportów z tej witryny.

6.03. (f)

Proszę określić mechanizmy kontroli stosowane do ochrony przed złośliwym kodem.

Firma Atlassian wdrożyła platformę Crowdstrike Falcon (https://www.crowdstrike.com/falcon-platform/) na potrzeby naszej floty komputerów z systemami Windows i Mac. Nie używamy oprogramowania chroniącego przed złośliwym kodem na komputerach z systemem Linux. Oprogramowanie chroniące przed złośliwym kodem jest uwzględnione w naszych zasadach zarządzania lukami w zabezpieczeniach.

Przestrzegamy zasad zarządzania zagrożeniami i lukami w zabezpieczeniach. Zdefiniowaliśmy również program Policy Management Program (PMP), który obejmuje obowiązki związane z własnością, dostępnością i cyklem weryfikacji oraz określa nasze ogólne cele. Nasze zasady są sprawdzane co najmniej raz w roku i zatwierdzane przez kierownictwo wyższego szczebla. Więcej informacji na temat naszego programu PMP można znaleźć pod adresem: https://www.atlassian.com/trust/security/security-management-program.

Opublikowaliśmy również fragmenty z poszczególnych zasad ogólnych w wersji skróconej, które można znaleźć pod adresem: https://www.atlassian.com/trust/security/ismp-policies.

6.03. (g)

Czy wdrożono bezpieczne konfiguracje umożliwiające wykonywanie tylko autoryzowanego kodu mobilnego i autoryzowanych funkcji (np. tylko określonych poleceń)?

Wszystkie serwery są konfigurowane przy użyciu naszego scentralizowanego systemu konfiguracji Puppet do naszego standardowego środowiska operacyjnego, co obejmuje usuwanie wybranych pakietów z domyślnego obrazu i krytyczne aktualizacje pakietów. Wszystkie role serwera zakładają domyślne odrzucanie wszystkich dla przychodzących żądań sieciowych, przy czym wybrane porty są otwierane tylko dla innych ról serwera, które wymagają dostępu do tego portu dla ich funkcji.

Nasza sieć korporacyjna jest odseparowana od naszej sieci produkcyjnej, a obrazy naszych maszyn są wzmocnione, aby zezwalać tylko na niezbędne porty i protokoły. Wszystkie systemy produkcyjne są obecnie hostowane w USA, w regionach działalności naszego dostawcy chmury. Wszystkie dane przesyłane poza wzmocnionymi sieciami wirtualnych chmur prywatnych (VPC) są szyfrowane za pośrednictwem kanałów zgodnych ze standardami branżowymi.

Ponadto na wszystkich serwerach produkcyjnych działa system IDS, który obejmuje monitorowanie w czasie rzeczywistym i powiadamianie o wszelkich zmianach w plikach systemu produkcyjnego lub konfiguracji oraz o anomaliach w zabezpieczeniach.

Wdrożyliśmy także scentralizowane rozwiązanie do zarządzania systemem (https://www.jamf.com/lp/apple-mobile-device-management-mdm-jamf/) do naszej floty laptopów Mac. Na naszych laptopach stosujemy pełne szyfrowanie dysków. Co więcej, wdrożyliśmy rozwiązanie do zarządzania urządzeniami mobilnymi w naszych smartfonach (https://www.vmware.com/products/workspace-one.html). Aby uzyskać dostęp do wewnętrznych systemów i aplikacji, wszystkie urządzenia muszą być zarejestrowane. Jeśli urządzenie mobilne nie jest zarejestrowane, nie może uzyskać dostępu do żadnych zasobów wewnętrznych i znajduje się w sieci gościnnej, za pośrednictwem której można uzyskać dostęp tylko do Internetu. Dostęp jest zarządzany za pomocą kontroli dostępu opartej na rolach, aby zapewnić, że mają go tylko użytkownicy wymagający dostępu do danych klienta/dzierżawcy.

6.03. (h)

Opisz szczegółowo zasady i procedury tworzenia kopii zapasowych. Powinno to obejmować procedury zarządzania nośnikami wymiennymi oraz metody bezpiecznego niszczenia niepotrzebnych nośników. (W zależności od wymagań biznesowych klient może chcieć wdrożyć niezależną strategię tworzenia kopii zapasowych. Jest to szczególnie istotne, gdy wymagany jest natychmiastowy dostęp do kopii zapasowej).

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 dane są replikowane do innego regionu AWS, a w każdym regionie codziennie wykonywane są niezależne kopie zapasowe.

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. Klienci powinni również wykonywać własne okresowe kopie zapasowe, aby móc wycofać zmiany zainicjowane przez klienta. Więcej informacji można znaleźć na stronie https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/#Can-Atlassian%E2%80%99s-RDS-backups-be-used-to-roll-back-changes.

Atlassian przestrzega standardów dotyczących przechowywania i niszczenia danych, które określają, jak długo musimy zatrzymywać różnego rodzaju dane. Dane są klasyfikowane zgodnie z zasadami firmy Atlassian dotyczącymi bezpieczeństwa danych i cyklu życia informacji, a na tej podstawie wdrażane są środki kontroli. Jeśli chodzi o dane klienta, w momencie rozwiązania umowy z firmą Atlassian dane należące do zespołu klienta zostaną usunięte z aktywnej produkcyjnej bazy danych, a wszystkie pliki załączników przekazane bezpośrednio do firmy Atlassian zostaną usunięte w ciągu 14 dni. Dane zespołu zostaną zachowane w zaszyfrowanych kopiach zapasowych przez 90 dni, a następnie zniszczone zgodnie z zasadami przechowywania danych firmy Atlassian. Jeśli w ciągu 90 dni od zażądania usunięcia danych konieczne okaże się przywrócenie bazy danych, zespół odpowiedzialny za eksploatację systemów ponownie usunie dane możliwie jak najszybciej po pełnym przywróceniu aktywnego systemu produkcyjnego. Więcej informacji można znaleźć na stronie https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Dzienniki audytu są wykorzystywane w przypadku incydentu wymagającego zbadania, a także do rozwiązywania problemów. Klient końcowy musi mieć pewność, że takie informacje są dostępne.

6.03. (i)

Czy dostawca może wyszczególnić, jakie informacje są rejestrowane w dziennikach audytu?

• Przez jaki okres są przechowywane te dane?
• Czy możliwe jest segmentowanie danych w dziennikach audytu, tak aby można je było udostępnić klientowi końcowemu i/lub organom ścigania bez narażania innych klientów i nadal były uznawane w sądzie?
• Jakie środki kontroli są stosowane w celu ochrony dzienników przed nieautoryzowanym dostępem lub manipulacją?
• Jaka metoda jest używana do sprawdzania i ochrony integralności dzienników audytu?

Dzienniki kluczowych systemów są przekazywane z każdego systemu do scentralizowanej platformy dzienników, gdzie są one dostępne tylko do odczytu. Zespół ds. bezpieczeństwa Atlassian tworzy alerty na naszej platformie analizy zabezpieczeń (Splunk) i monitoruje wskaźniki pod kątem naruszeń. Nasze zespoły inżynierów ds. niezawodności lokalizacji (SRE) wykorzystują tę platformę do monitorowania problemów z dostępnością lub wydajnością. Dzienniki są przechowywane przez 30 dni w dynamicznej kopii zapasowej i przez 365 dni w kopii zapasowej offline.

Atlassian ogranicza możliwość przeglądania i odczytywania dzienników audytu do upoważnionego personelu na naszej scentralizowanej platformie do rejestrowania dzienników.

Atlassian przestrzega standardów dotyczących przechowywania i niszczenia danych, które określają, jak długo musimy zatrzymywać różnego rodzaju dane. Dane są klasyfikowane zgodnie z zasadami firmy Atlassian dotyczącymi bezpieczeństwa danych i cyklu życia informacji, a na tej podstawie wdrażane są środki kontroli. Jeśli chodzi o dane klienta, w momencie rozwiązania umowy z firmą Atlassian dane należące do zespołu klienta zostaną usunięte z aktywnej produkcyjnej bazy danych, a wszystkie pliki załączników przekazane bezpośrednio do firmy Atlassian zostaną usunięte w ciągu 14 dni. Dane zespołu zostaną zachowane w zaszyfrowanych kopiach zapasowych przez 90 dni, a następnie zniszczone zgodnie z zasadami przechowywania danych firmy Atlassian. Jeśli w ciągu 90 dni od zażądania usunięcia danych konieczne okaże się przywrócenie bazy danych, zespół odpowiedzialny za eksploatację systemów ponownie usunie dane możliwie jak najszybciej po pełnym przywróceniu aktywnego systemu produkcyjnego. Więcej informacji można znaleźć na stronie https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

6.03. (j)

W jaki sposób są sprawdzane dzienniki audytu? Jakie zarejestrowane zdarzenia skutkują podjęciem działań?

Dzienniki kluczowych systemów są przekazywane z każdego systemu do scentralizowanej platformy dzienników, gdzie są one dostępne tylko do odczytu. Zespół ds. bezpieczeństwa Atlassian tworzy alerty na naszej platformie analizy zabezpieczeń (Splunk) i monitoruje wskaźniki pod kątem naruszeń. Nasze zespoły inżynierów ds. niezawodności lokalizacji (SRE) wykorzystują tę platformę do monitorowania problemów z dostępnością lub wydajnością. Dzienniki są przechowywane przez 30 dni w dynamicznej kopii zapasowej i przez 365 dni w kopii zapasowej offline.

Atlassian ogranicza możliwość przeglądania i odczytywania dzienników audytu do upoważnionego personelu na naszej scentralizowanej platformie do rejestrowania dzienników.

6.03. (k)

Jakie źródło czasu służy do synchronizacji systemów i zapewnienia dokładnych znaczników czasu w dzienniku audytu?

Atlassian Cloud korzysta we wszystkich wdrożonych instancjach z usługi AWS Time Sync.

6.03.01. (a)

Zdefiniuj mechanizmy kontroli stosowane w celu ochrony integralności systemu operacyjnego i używanych aplikacji. Uwzględnij wszelkie przestrzegane standardy, np. OWASP, SANS Checklist, SAFECode.

Nasz zespół inżynierów ds. bezpieczeństwa dokonuje ciągłego przeglądu całego kodu źródłowego produktów w ramach cyklu rozwoju. Wykorzystywane są zarówno techniki automatyczne, jak i ręczne. Stosujemy również obowiązkowy proces podwójnej wzajemnej weryfikacji — wielu starszych lub głównych programistów sprawdza wszystkie commity do wersji master. Przepływy pracy w modelu Agile pozwalają nam szybko identyfikować i eliminować wszelkie luki w zabezpieczeniach, zwłaszcza w przypadku naszych usług chmurowych.

Proces bezpiecznego przeglądu kodu prowadzony przez Atlassian obejmuje automatyczne skanowanie (tj. analizę składu oprogramowania) pod kątem znanych luk w zabezpieczeniach, w tym tych wykorzystywanych w rzeczywistych atakach. Ponadto nasz program zarządzania lukami w zabezpieczeniach skanuje hosty i obrazy kontenerów pod kątem znanych luk w zabezpieczeniach za pomocą Snyk. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/security/vulnerability-management.

Współpracujemy z BugCrowd przy prowadzeniu programu Bug Bounty mającego na celu przeprowadzanie bieżących ocen luk w zabezpieczeniach naszych publicznie dostępnych aplikacji i usług. Program jest dostępny na stronie https://bugcrowd.com/atlassian. Udostępniamy bieżące wyniki testów penetracyjnych z naszego programu Bug Bounty pod adresem https://www.atlassian.com/trust/security/security-testing.

6.03.01. (b)

Jak zweryfikować, czy nowe wersje są odpowiednie do celu lub czy nie zawierają zagrożeń (backdoorów, trojanów itp.)? Czy są one sprawdzane przed użyciem?

Proces zarządzania zmianami stosowany przez Atlassian różni się nieco od tradycyjnych procesów zmian. W przypadku wszystkich zmian — niezależnie od tego, czy chodzi o zmiany w kodzie, aplikacjach czy infrastrukturze — polegamy na kontroli Peer Review and Green Build (PRGB). Proces Peer Review jest skonfigurowany w naszym narzędziu CD. W jego ramach należy wyznaczyć krytyczne gałęzie, aby mieć wielu recenzentów dla każdego pull requesta. Zazwyczaj jest to dwóch programistów i lider zespołu. Natomiast w ramach procesu Green Build integracja w fazie CI musi przejść pomyślnie wszystkie opracowane testy, m.in. integracyjne, funkcjonalne i bezpieczeństwa. Jeśli testy te zakończą się niepowodzeniem (Red Build), kod nie zostanie scalony i należy go ponownie sprawdzić oraz usunąć błędy. Po pomyślnym przeprowadzeniu procesu Green Build plik binarny jest podpisywany kryptograficznie, a w naszym środowisku produkcyjnym uruchamiane są wyłącznie pliki binarne podpisane naszym kluczem. Nasz proces testowania obejmuje zarówno zautomatyzowane, jak i ręczne elementy oceny. Uwielbiamy blogować o tym, co robimy dobrze. Nasze podejście do korzystania z procedury „Quality Assistance” (zamiast tradycyjnego „Quality Assurance”) jest naszą pasją: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance.

Po wdrożeniu stosujemy regularne automatyczne skanowanie pod kątem luk w zabezpieczeniach i czołowy w branży program wykrywania błędów Bug Bounty (https://bugcrowd.com/atlassian), aby bezpieczeństwo naszych aplikacji było stale poddawane kontroli. Zmiany konfiguracji systemu są zarządzane w ramach zautomatyzowanego procesu, który obejmuje przegląd.

Proces bezpiecznego przeglądu kodu prowadzony przez Atlassian obejmuje automatyczne skanowanie (tj. analizę składu oprogramowania) pod kątem znanych luk w zabezpieczeniach, w tym tych wykorzystywanych w rzeczywistych atakach. Ponadto nasz program zarządzania lukami w zabezpieczeniach skanuje hosty i obrazy kontenerów pod kątem znanych luk w zabezpieczeniach za pomocą Snyk. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/security/vulnerability-management.

6.03.01. (c)

Jakie praktyki są stosowane w celu zapewnienia bezpieczeństwa aplikacji?

Nasze aplikacje wymagają przeprowadzenia procesu Peer Review and Green Build (PRGB), po którym artefakty aplikacji są podpisywane kryptograficznie oraz automatycznie wdrażane przez nasz pipeline CI/CD i tylko aplikacje podpisane przez Atlassian mogą być uruchamiane w naszym środowisku produkcyjnym.

Atlassian stosuje bezpieczne praktyki programistyczne na wszystkich etapach cyklu tworzenia produktów. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/security/security-in-development.

Na etapie projektowania praktyki obejmują modelowanie zagrożeń, przegląd projektu i naszą regularnie aktualizowaną bibliotekę standardów bezpieczeństwa, dzięki czemu mamy pewność, że wymagania dotyczące zabezpieczeń są uwzględniane. W trakcie tworzenia oprogramowania stosujemy obowiązkowy proces wzajemnej oceny, który stanowi pierwszy stopień przeglądu bezpieczeństwa. W ramach wsparcia na tym etapie przeprowadza się zautomatyzowane kontrole oparte na analizie statycznej (SAST) oraz ręczne testy zabezpieczeń (z udziałem zarówno zespołów wewnętrznych, jak i ekspertów z zewnątrz, zgodnie z naszym procesem oceny ryzyka). W ramach wspierania procesu tworzenia produktów prowadzimy również programy szkoleń w zakresie bezpieczeństwa aplikacji oraz bazę wiedzy na temat bezpieczeństwa, za które odpowiada specjalny zespół ds. bezpieczeństwa. Dzięki procesom formalnej gotowości operacyjnej oraz kontrolowania zmian zyskujemy pewność, że do produkcji wdrażane są tylko zatwierdzone zmiany. Po wdrożeniu stosujemy regularne automatyczne skanowanie pod kątem luk w zabezpieczeniach i czołowy w branży program wykrywania błędów Bug Bounty (https://bugcrowd.com/atlassian), aby bezpieczeństwo naszych aplikacji było stale poddawane kontroli. Zmiany w konfiguracji systemu są zarządzane przez zautomatyzowany proces, który obejmuje przegląd wszystkich zmian przed wdrożeniem do produkcji. Dział eksploatacji usług Atlassian może wdrażać poprawki natychmiast po zidentyfikowaniu istotnego ryzyka. Mamy wewnętrzne kryteria określające, jak szybko wdrożyć wszelkie poprawki, i możemy je zastosować w ciągu 12 godzin na wszystkich urządzeniach. Funkcjonuje również system IDS, który obejmuje monitorowanie plików konfiguracyjnych systemu.

6.03.01. (d)

Czy wydanie oprogramowania jest poddawane testom penetracyjnym, aby upewnić się, że nie zawiera ono luk w zabezpieczeniach? Jeśli zostaną wykryte luki w zabezpieczeniach, jaki jest proces ich usuwania?

Atlassian stosuje bezpieczne praktyki programistyczne na wszystkich etapach cyklu tworzenia produktów. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/security/security-in-development.

W trakcie tworzenia oprogramowania stosujemy obowiązkowy proces wzajemnej oceny, który stanowi pierwszy stopień przeglądu bezpieczeństwa. W ramach wsparcia na tym etapie przeprowadza się zautomatyzowane kontrole oparte na analizie statycznej (SAST) oraz ręczne testy zabezpieczeń (z udziałem zarówno zespołów wewnętrznych, jak i ekspertów z zewnątrz, zgodnie z naszym procesem oceny ryzyka). W ramach wspierania procesu tworzenia produktów prowadzimy również programy szkoleń w zakresie bezpieczeństwa aplikacji oraz bazę wiedzy na temat bezpieczeństwa, za które odpowiada specjalny zespół ds. bezpieczeństwa.

Dzięki procesom formalnej gotowości operacyjnej oraz kontrolowania zmian zyskujemy pewność, że do produkcji wdrażane są tylko zatwierdzone zmiany. Po wdrożeniu stosujemy regularne automatyczne skanowanie pod kątem luk w zabezpieczeniach i czołowy w branży program wykrywania błędów Bug Bounty (https://bugcrowd.com/atlassian), aby bezpieczeństwo naszych aplikacji było stale poddawane kontroli.

6.03.02. (a)

Jakich używacie procedur zarządzania poprawkami?

Przestrzegamy zasad zarządzania zagrożeniami i lukami w zabezpieczeniach. Zdefiniowaliśmy również program Policy Management Program (PMP), który obejmuje obowiązki związane z własnością, dostępnością i cyklem weryfikacji oraz określa nasze ogólne cele. Nasze zasady są sprawdzane co najmniej raz w roku i zatwierdzane przez kierownictwo wyższego szczebla. Więcej informacji na temat naszego programu PMP można znaleźć pod adresem: https://www.atlassian.com/trust/security/security-management-program.

Opublikowaliśmy również fragmenty z poszczególnych zasad ogólnych w wersji skróconej, które można znaleźć pod adresem: https://www.atlassian.com/trust/security/ismp-policies.

Atlassian wykorzystuje kombinację zarządzania punktami końcowymi do wdrażania aktualizacji i poprawek w systemach operacyjnych i kluczowych aplikacjach całej naszej floty urządzeń końcowych. Wdrożyliśmy również wiele rozwiązań mających na celu ochronę punktów końcowych przed takimi zagrożeniami jak złośliwe oprogramowanie. Więcej informacji można znaleźć na stronie: https://www.atlassian.com/trust/security/security-practices#keeping-track-of-information-assets.

6.03.02. (b)

Czy możesz zapewnić, że proces zarządzania poprawkami obejmuje wszystkie warstwy technologii dostarczania chmury — tj. sieć (komponenty infrastruktury, routery i przełączniki itp.), systemy operacyjne serwerów, oprogramowanie do wirtualizacji, aplikacje i podsystemy bezpieczeństwa (zapory, bramy antywirusowe, systemy wykrywania włamań itp.)?

Zmiany w konfiguracji systemu są zarządzane przez zautomatyzowany proces, który obejmuje przegląd wszystkich zmian przed wdrożeniem do produkcji. Dział eksploatacji usług Atlassian może wdrażać poprawki natychmiast po zidentyfikowaniu istotnego ryzyka. Mamy wewnętrzne kryteria określające, jak szybko wdrożyć wszelkie poprawki, i możemy je zastosować w ciągu 12 godzin na wszystkich urządzeniach. Wdrożony jest system IDS, który obejmuje monitorowanie plików konfiguracyjnych systemu.

Produkty Atlassian Cloud można aktualizować do najnowszej wersji AMI tak szybko, jak to konieczne. Nasze aplikacje SaaS są aktualizowane kilka razy w tygodniu. Dysponujemy szybkimi i kontrolowanymi mechanizmami wdrażania aktualizacji w kodzie i konfiguracjach systemu. Atlassian aktywnie korzysta z kontroli zmian w przypadku zmian nieplanowanych i awaryjnych.

6.03.03. (a)

Zdefiniuj mechanizmy kontroli używane do łagodzenia skutków ataków DDoS.

• Dogłębna ochrona (głęboka analiza pakietów, ograniczanie ruchu, blokowanie pakietów itp.).
• Czy dysponujecie zabezpieczeniami przed atakami zarówno wewnętrznymi (pochodzącymi z sieci dostawców usług w chmurze), jak i zewnętrznymi (pochodzącymi z Internetu lub sieci klientów)?
<

Wymagania dotyczące bezpieczeństwa sieci są określone w Zasadach bezpieczeństwa komunikacji, które są corocznie poddawane przeglądowi zgodnie z naszym programem Policy Management Program (PMP). Więcej informacji na temat programu PMP można znaleźć na stronie https://www.atlassian.com/trust/security/security-management-program.

Nasza platforma Atlassian Cloud ma bardzo niewielką powierzchnię, która jest odsłonięta przez zapory. Dokonujemy regularnych przeglądów reguł zapory. Wdrożyliśmy technologię IDS w naszych biurach oraz naszym środowisku hostingu w chmurze. Przekazywanie dzienników związanych z platformą Atlassian Cloud jest zintegrowane z platformą analizy zabezpieczeń. Na poziomie kontenera platformy Cloud integralność plików jest zachowana, ponieważ instancje nie są możliwe do modyfikacji. Dział inżynierii sieci firmy Atlassian wykorzystuje technologie IPS wbudowane w nasze zapory, a ponadto wdrożyliśmy w naszych środowiskach biurowych i chmurowych technologie IDS. Funkcje ochrony przed atakami DDoS zapewnia nasz dostawca usług internetowych / operator.

Wydajność naszych zapór jest również regularnie oceniana poprzez nasze programy oceny luk w zabezpieczeniach (https://www.atlassian.com/trust/security/vulnerability-management) i testów penetracyjnych (https://www.atlassian.com/trust/security/security-testing).

6.03.03. (b)

Jakie poziomy izolacji są stosowane?

• W odniesieniu do maszyn wirtualnych, maszyn fizycznych, sieci, pamięci masowej (np. SAN), sieci zarządzania i systemów wsparcia zarządzania itp.
<

Atlassian to aplikacja SaaS z wielodostępem. Jedną z kluczowych cech rozwiązania Atlassian Cloud jest wielodostęp, który umożliwia wielu klientom współdzielenie jednej instancji warstwy aplikacji Jira lub Confluence, jednocześnie zapewniając odizolowanie danych aplikacji każdej dzierżawy. Atlassian Cloud realizuje to za pośrednictwem usługi TCS (Tenant Context Service). Każdy identyfikator użytkownika jest powiązany z dokładnie jedną dzierżawą, która następnie służy do uzyskania dostępu do aplikacji Atlassian Cloud. Więcej informacji można znaleźć na stronie: https://www.atlassian.com/trust/security/security-practices#tenant-isolation

Zachowujemy logiczną i fizyczną separację środowisk produkcyjnych i nieprodukcyjnych (używanych do tworzenia oprogramowania) w przypadku wszystkich środowisk i metod stosowanych do ich izolowania.

Nasze środowisko przejściowe jest logicznie (ale nie fizycznie) oddzielone i zarządzane z zastosowaniem procesów dostępu i kontrolowania zmian klasy produkcyjnej.

6.03.03. (c)

Czy architektura wspiera dalsze działanie z poziomu chmury, gdy firma jest odseparowana od usługodawcy i odwrotnie (np. czy istnieje krytyczna zależność od systemu LDAP klienta)?

Obowiązują zasady „Zachowanie ciągłości działania i odzyskiwanie awaryjne” oraz „Plan odzyskiwania awaryjnego i ciągłości działalności biznesowej”. Są one co roku poddawane przeglądowi przez komitet sterujący ds. ciągłości działalności biznesowej / odzyskiwania awaryjnego. Więcej informacji można znaleźć na stronie: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e i https://www.atlassian.com/trust/security/data-management.

Atlassian wykorzystuje wysoce dostępne obiekty centrów danych AWS w wielu regionach na całym świecie, aby zapewnić ciągłą pracę. Więcej informacji można znaleźć na stronie: https://www.atlassian.com/trust/security/data-management.

6.03.03. (d)

Czy infrastruktura sieci wirtualnej używana przez dostawców usług w chmurze (w architekturze tagowania sieci PVLAN i VLAN 802.1q) jest zabezpieczona zgodnie ze standardami specyficznymi dla dostawców i/lub według najlepszych praktyk (np. czy zapobiega się atakom MAC spoofing, ARP poisoning itp. za pomocą określonej konfiguracji zabezpieczeń)?

Wymagania dotyczące bezpieczeństwa sieci są określone w „Zasadach bezpieczeństwa komunikacji”, które są corocznie poddawane przeglądowi zgodnie z naszym programem Policy Management Program (PMP). Więcej informacji na temat programu PMP można znaleźć na stronie: https://www.atlassian.com/trust/security/security-management-program

Bardzo niewielka powierzchnia naszej platformy Atlassian Cloud jest widoczna przez zapory. Dokonujemy regularnych przeglądów reguł zapory. Wdrożyliśmy technologię IDS w naszych biurach oraz naszym środowisku hostingu w chmurze. Przekazywanie dzienników związanych z platformą Atlassian Cloud jest zintegrowane z platformą analizy zabezpieczeń. Na poziomie kontenera platformy Cloud integralność plików jest zachowana, ponieważ instancje nie są możliwe do modyfikacji. Dział inżynierii sieci firmy Atlassian wykorzystuje technologie IPS wbudowane w nasze zapory, a ponadto wdrożyliśmy w naszych środowiskach biurowych i chmurowych technologie IDS. Funkcjonalności DDoS są dostarczane przez naszego dostawcę usług internetowych / operatora.

Wydajność naszych zapór jest również regularnie oceniana poprzez nasze programy oceny luk w zabezpieczeniach (https://www.atlassian.com/trust/security/vulnerability-management) i testów penetracyjnych (https://www.atlassian.com/trust/security/security-testing) .

Ponadto w Atlassian monitorujemy konfigurację naszych środowisk AWS pod kątem zgodności z ustalonymi parametrami bazowymi.

6.03.04. (a)

Czy dostawca zapewnia domyślne ograniczanie funkcjonalności obrazów wirtualnych?

Wszystkie serwery są konfigurowane przy użyciu naszego scentralizowanego systemu konfiguracji Puppet do naszego standardowego środowiska operacyjnego, co obejmuje usuwanie wybranych pakietów z domyślnego obrazu i krytyczne aktualizacje pakietów. Wszystkie role serwera zakładają domyślne odrzucanie wszystkich przychodzących żądań sieciowych, przy czym wybrane porty są otwierane tylko dla innych ról serwera, których funkcjonowanie wymaga dostępu do tego portu.

Nasza sieć korporacyjna jest odseparowana od naszej sieci produkcyjnej, a obrazy naszych maszyn mają ograniczone funkcjonalności, aby zezwalać tylko na niezbędne porty i protokoły. Wszystkie systemy produkcyjne są obecnie hostowane w Stanach Zjednoczonych, w regionach działalności naszego dostawcy chmury. Wszystkie dane przesyłane poza sieciami wirtualnych chmur prywatnych (VPC) o ograniczonej funkcjonalności są szyfrowane za pośrednictwem kanałów zgodnych ze standardami branżowymi.

Ponadto na wszystkich serwerach produkcyjnych działa system IDS, który obejmuje monitorowanie w czasie rzeczywistym i powiadamianie o wszelkich zmianach w plikach systemu produkcyjnego lub konfiguracji oraz o anomaliach w zabezpieczeniach.

Poszczególne kontenery platformy Atlassian Cloud nie mają obrazu, a gdy kontener jest inicjowany, obraz jest wybierany ze standardowego repozytorium. Prowadzimy bieżący audyt każdego z obrazów i w razie konieczności zapewniamy ponowną aplikację obrazów za pomocą naszych narzędzi konfiguracyjnych. W rezultacie w obrazach maszyn wirtualnych nie są wprowadzane żadne zmiany.

Kompilacje podstawowego obrazu systemu operacyjnego AWS Linux AMI mają ograniczone porty, protokoły i usługi. Porównujemy nasze kompilacje z obecną wersją AMI, aby zapewnić odpowiednie ustawienia.

Nasze obrazy Docker są zarządzane w ściśle kontrolowanym środowisku zmian, aby umożliwić odpowiedni przegląd i zatwierdzanie wszelkich zmian.

6.03.04. (b)

Czy obraz wirtualny o ograniczonej funkcjonalności jest chroniony przed nieautoryzowanym dostępem?

Wszystkie serwery są konfigurowane przy użyciu naszego scentralizowanego systemu konfiguracji Puppet do naszego standardowego środowiska operacyjnego, co obejmuje usuwanie wybranych pakietów z domyślnego obrazu i krytyczne aktualizacje pakietów. Wszystkie role serwera zakładają domyślne odrzucanie wszystkich przychodzących żądań sieciowych, przy czym wybrane porty są otwierane tylko dla innych ról serwera, których funkcjonowanie wymaga dostępu do tego portu.

Nasza sieć korporacyjna jest odseparowana od naszej sieci produkcyjnej, a obrazy naszych maszyn mają ograniczone funkcjonalności, aby zezwalać tylko na niezbędne porty i protokoły. Wszystkie systemy produkcyjne są obecnie hostowane w Stanach Zjednoczonych, w regionach działalności naszego dostawcy chmury. Wszystkie dane przesyłane poza sieciami wirtualnych chmur prywatnych (VPC) o ograniczonej funkcjonalności są szyfrowane za pośrednictwem kanałów zgodnych ze standardami branżowymi.

Ponadto na wszystkich serwerach produkcyjnych działa system IDS, który obejmuje monitorowanie w czasie rzeczywistym i powiadamianie o wszelkich zmianach w plikach systemu produkcyjnego lub konfiguracji oraz o anomaliach w zabezpieczeniach.

Poszczególne kontenery platformy Atlassian Cloud nie mają obrazu, a gdy kontener jest inicjowany, obraz jest wybierany ze standardowego repozytorium. Prowadzimy bieżący audyt każdego z obrazów i w razie konieczności zapewniamy ponowną aplikację obrazów za pomocą naszych narzędzi konfiguracyjnych. W rezultacie w obrazach maszyn wirtualnych nie są wprowadzane żadne zmiany.

Kompilacje podstawowego obrazu systemu operacyjnego AWS Linux AMI mają ograniczone porty, protokoły i usługi. Porównujemy nasze kompilacje z obecną wersją AMI, aby zapewnić odpowiednie ustawienia.

Nasze obrazy Docker są zarządzane w ściśle kontrolowanym środowisku zmian, aby umożliwić odpowiedni przegląd i zatwierdzanie wszelkich zmian.

Nasz globalny zespół wsparcia technicznego prowadzi konto na wszystkich hostowanych systemach i aplikacjach w celu zapewnienia konserwacji i wsparcia. Zespół wsparcia uzyskuje dostęp do hostowanych aplikacji oraz danych wyłącznie w celu monitorowania kondycji aplikacji oraz przeprowadzenia konserwacji systemu lub aplikacji, bądź na wniosek klienta przesłany za pośrednictwem naszego systemu wsparcia.

6.03.04. (c)

Czy dostawca może potwierdzić, że zwirtualizowany obraz nie zawiera danych uwierzytelniających?

Wszystkie serwery są konfigurowane przy użyciu naszego scentralizowanego systemu konfiguracji Puppet do naszego standardowego środowiska operacyjnego, co obejmuje usuwanie wybranych pakietów z domyślnego obrazu i krytyczne aktualizacje pakietów. Wszystkie role serwera zakładają domyślne odrzucanie wszystkich przychodzących żądań sieciowych, przy czym wybrane porty są otwierane tylko dla innych ról serwera, których funkcjonowanie wymaga dostępu do tego portu.

Nasza sieć korporacyjna jest odseparowana od naszej sieci produkcyjnej, a obrazy naszych maszyn mają ograniczone funkcjonalności, aby zezwalać tylko na niezbędne porty i protokoły. Wszystkie systemy produkcyjne są obecnie hostowane w Stanach Zjednoczonych, w regionach działalności naszego dostawcy chmury. Wszystkie dane przesyłane poza sieciami wirtualnych chmur prywatnych (VPC) o ograniczonej funkcjonalności są szyfrowane za pośrednictwem kanałów zgodnych ze standardami branżowymi.

Ponadto na wszystkich serwerach produkcyjnych działa system IDS, który obejmuje monitorowanie w czasie rzeczywistym i powiadamianie o wszelkich zmianach w plikach systemu produkcyjnego lub konfiguracji oraz o anomaliach w zabezpieczeniach.

Poszczególne kontenery platformy Atlassian Cloud nie mają obrazu, a gdy kontener jest inicjowany, obraz jest wybierany ze standardowego repozytorium. Prowadzimy bieżący audyt każdego z obrazów i w razie konieczności zapewniamy ponowną aplikację obrazów za pomocą naszych narzędzi konfiguracyjnych. W rezultacie w obrazach maszyn wirtualnych nie są wprowadzane żadne zmiany.

Kompilacje podstawowego obrazu systemu operacyjnego AWS Linux AMI mają ograniczone porty, protokoły i usługi. Porównujemy nasze kompilacje z obecną wersją AMI, aby zapewnić odpowiednie ustawienia.

Nasze obrazy Docker są zarządzane w ściśle kontrolowanym środowisku zmian, aby umożliwić odpowiedni przegląd i zatwierdzanie wszelkich zmian.

Nasz globalny zespół wsparcia technicznego prowadzi konto na wszystkich hostowanych systemach i aplikacjach w celu zapewnienia konserwacji i wsparcia. Zespół wsparcia uzyskuje dostęp do hostowanych aplikacji oraz danych wyłącznie w celu monitorowania kondycji aplikacji oraz przeprowadzenia konserwacji systemu lub aplikacji, bądź na wniosek klienta przesłany za pośrednictwem naszego systemu wsparcia.

6.03.04. (d)

Czy zapora hosta działa tylko z minimalną liczbą portów niezbędnych do wspierania usług w instancji wirtualnej?

Wszystkie serwery są konfigurowane przy użyciu naszego scentralizowanego systemu konfiguracji Puppet do naszego standardowego środowiska operacyjnego, co obejmuje usuwanie wybranych pakietów z domyślnego obrazu i krytyczne aktualizacje pakietów. Wszystkie role serwera zakładają domyślne odrzucanie wszystkich przychodzących żądań sieciowych, przy czym wybrane porty są otwierane tylko dla innych ról serwera, których funkcjonowanie wymaga dostępu do tego portu.

Nasza sieć korporacyjna jest odseparowana od naszej sieci produkcyjnej, a obrazy naszych maszyn mają ograniczone funkcjonalności, aby zezwalać tylko na niezbędne porty i protokoły. Wszystkie systemy produkcyjne są obecnie hostowane w Stanach Zjednoczonych, w regionach działalności naszego dostawcy chmury. Wszystkie dane przesyłane poza sieciami wirtualnych chmur prywatnych (VPC) o ograniczonej funkcjonalności są szyfrowane za pośrednictwem kanałów zgodnych ze standardami branżowymi.

Bardzo niewielka powierzchnia naszej platformy Atlassian Cloud jest widoczna przez zapory. Dokonujemy regularnych przeglądów reguł zapory. Wdrożyliśmy technologię IDS w naszych biurach oraz naszym środowisku hostingu w chmurze. Przekazywanie dzienników związanych z platformą Atlassian Cloud jest zintegrowane z platformą analizy zabezpieczeń. Na poziomie kontenera platformy Cloud integralność plików jest zachowana, ponieważ instancje nie są możliwe do modyfikacji. Dział inżynierii sieci firmy Atlassian wykorzystuje technologie IPS wbudowane w nasze zapory, a ponadto wdrożyliśmy w naszych środowiskach biurowych i chmurowych technologie IDS. Funkcjonalności DDoS są dostarczane przez naszego dostawcę usług internetowych / operatora.

Wydajność naszych zapór jest również regularnie oceniana poprzez nasze programy oceny luk w zabezpieczeniach (https://www.atlassian.com/trust/security/vulnerability-management) i testów penetracyjnych (https://www.atlassian.com/trust/security/security-testing) .

6.03.04. (e)

Czy oparta na hoście usługa zapobiegania włamaniom (IPS) może być uruchomiona w instancji wirtualnej?

Nie ma to zastosowania, ponieważ Atlassian obsługuje model SaaS (oprogramowanie jako usługa).

6.03.05.

Dostawcy usług PaaS odpowiadają za bezpieczeństwo stosu oprogramowania platformy, a zalecenia zawarte w tym dokumencie stanowią dobrą podstawę do tego, aby dostawca PaaS uwzględnił zasady bezpieczeństwa podczas projektowania swojej platformy PaaS i zarządzania nią. Często trudno jest uzyskać od dostawców PaaS szczegółowe informacje na temat tego, jak dokładnie zabezpieczają swoje platformy — poniższe pytania, a także inne sekcje tego dokumentu, powinny być pomocne w ocenie ich ofert.

6.03.05. (a)

Poproś o informacje na temat sposobu odizolowania od siebie aplikacji z wielodostępem — potrzebny będzie ogólny opis środków ograniczania i izolacji.

Nie ma to zastosowania, ponieważ Atlassian obsługuje model SaaS (oprogramowanie jako usługa).

6.03.05. (b)

Jaką gwarancję może dać dostawca PaaS, że dostęp do Twoich danych jest ograniczony wyłącznie do użytkowników w firmie i do posiadanych przez Ciebie aplikacji?

Nie ma to zastosowania, ponieważ Atlassian obsługuje model SaaS (oprogramowanie jako usługa).

6.03.05. (c)

Architektura platformy powinna być klasyczną „piaskownicą” — czy dostawca gwarantuje, że piaskownica platformy PaaS jest monitorowana pod kątem nowych błędów i luk w zabezpieczeniach?

Nie ma to zastosowania, ponieważ Atlassian obsługuje model SaaS (oprogramowanie jako usługa).

6.03.05. (d)

Dostawcy PaaS powinni oferować zestaw funkcji zabezpieczeń (nadający się do wielokrotnego użytku wśród ich klientów) — czy obejmują one uwierzytelnianie użytkowników, logowanie jednokrotne, autoryzację (zarządzanie uprawnieniami) i SSL/TLS (udostępniane przez API)?

Nie ma to zastosowania, ponieważ Atlassian obsługuje model SaaS (oprogramowanie jako usługa).

6.03.06.

Model SaaS zakłada, że dostawca zarządza całym pakietem aplikacji dostarczanych użytkownikom końcowym. Dlatego za zabezpieczenie tych aplikacji odpowiadają przede wszystkim dostawcy SaaS. Klienci są zwykle odpowiedzialni za procesy bezpieczeństwa operacyjnego (zarządzanie użytkownikami i dostępem). Poniższe pytania, a także inne sekcje tego dokumentu, powinny pomóc w ocenie ofert:

6.03.06. (a)

Jakie mechanizmy kontroli administracyjnej są dostępne i czy można ich użyć do przypisania uprawnień do odczytu i zapisu innym użytkownikom.

Klienci naszych planów Enterprise i Premium Cloud mają dostęp do centralnego panelu sterowania administracyjnego. Administratorzy organizacji mogą zarządzać dostępem użytkowników i uprawnieniami we wszystkich instancjach produktu. Zapoznaj się z naszym wpisem na blogu tutaj: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Klienci Atlassian mogą skorzystać z usług wybranego przez siebie zewnętrznego dostawcy tożsamości, jeśli jest obsługiwany przez Atlassian. Strona wsparcia Atlassian zawiera szczegółowe informacje na temat tych funkcji i sposobów podłączania wybranego dostawcy tożsamości: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.06. (b)

Czy kontrola dostępu SaaS jest szczegółowa i czy można ją dostosować do zasad organizacji?

Klienci naszych planów Enterprise i Premium Cloud mają dostęp do centralnego panelu sterowania administracyjnego. Administratorzy organizacji mogą zarządzać dostępem użytkowników i uprawnieniami we wszystkich instancjach produktu. Zapoznaj się z naszym wpisem na blogu tutaj: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Klienci Atlassian mogą skorzystać z usług wybranego przez siebie zewnętrznego dostawcy tożsamości, jeśli jest obsługiwany przez Atlassian. Strona wsparcia Atlassian zawiera szczegółowe informacje na temat tych funkcji i sposobów podłączania wybranego dostawcy tożsamości: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.07. (a)

W przypadku przeciążenia zasobów (przetwarzanie, pamięć, miejsce na dane, sieć):

• Jakie informacje są podawane na temat względnego priorytetu przypisanego mojemu wnioskowi w przypadku niepowodzenia aprowizacji?
• Czy istnieje czas wdrażania określony dla poziomów usług i zmian wymagań?
<

Atlassian planuje potencjał wykonawczy z wyprzedzeniem 6–12 miesięcy, a planowanie strategiczne na wysokim szczeblu obejmuje okres 36 miesięcy.

Atlassian utrzymuje dane analityczne na potrzeby architektury zwiększania i zmniejszania skali rozwiązań chmurowych AWS i Azure oraz wykorzystuje te dane do projektowania rozwiązań wspierających rozwój produktów Atlassian. Dane te nie są jednak obecnie przekazywane klientom.

6.03.07. (b)

Na ile można zwiększyć skalę? Czy dostawca oferuje gwarancje w zakresie maksymalnych dostępnych zasobów w minimalnym okresie?

Atlassian planuje potencjał wykonawczy z wyprzedzeniem 6–12 miesięcy, a planowanie strategiczne na wysokim szczeblu obejmuje okres 36 miesięcy.

Atlassian utrzymuje dane analityczne na potrzeby architektury zwiększania i zmniejszania skali rozwiązań chmurowych AWS i Azure oraz wykorzystuje te dane do projektowania rozwiązań wspierających rozwój produktów Atlassian. Dane te nie są jednak obecnie przekazywane klientom.

6.03.07. (c)

Jak szybko możesz zwiększyć skalę? Czy dostawca oferuje gwarancje w zakresie dostępności dodatkowych zasobów w minimalnym okresie?

Atlassian planuje potencjał wykonawczy z wyprzedzeniem 6–12 miesięcy, a planowanie strategiczne na wysokim szczeblu obejmuje okres 36 miesięcy.

Atlassian utrzymuje dane analityczne na potrzeby architektury zwiększania i zmniejszania skali rozwiązań chmurowych AWS i Azure oraz wykorzystuje te dane do projektowania rozwiązań wspierających rozwój produktów Atlassian. Dane te nie są jednak obecnie przekazywane klientom.

6.03.07. (d)

Jakie procesy są stosowane do obsługi trendów o dużej skali w zakresie zużycia zasobów (np. efekty sezonowe)?

Atlassian planuje potencjał wykonawczy z wyprzedzeniem 6–12 miesięcy, a planowanie strategiczne na wysokim szczeblu obejmuje okres 36 miesięcy.

Atlassian utrzymuje dane analityczne na potrzeby architektury zwiększania i zmniejszania skali rozwiązań chmurowych AWS i Azure oraz wykorzystuje te dane do projektowania rozwiązań wspierających rozwój produktów Atlassian. Dane te nie są jednak obecnie przekazywane klientom.

6.04.01.

Następujące mechanizmy kontroli mają zastosowanie do systemów zarządzania tożsamością i dostępem dostawcy chmury (znajdujących się pod jego kontrolą).

6.04.01. (a)

Czy jakiekolwiek konta mają uprawnienia systemowe do całego systemu chmury, a jeśli tak, to do których operacji (odczyt/zapis/usuwanie)?

Nasz globalny zespół wsparcia technicznego prowadzi konto na wszystkich hostowanych systemach i aplikacjach w celu zapewnienia konserwacji i wsparcia. Zespół wsparcia uzyskuje dostęp do hostowanych aplikacji oraz danych wyłącznie w celu monitorowania kondycji aplikacji oraz przeprowadzenia konserwacji systemu lub aplikacji, bądź na wniosek klienta przesłany za pośrednictwem naszego systemu wsparcia.

6.04.01. (b)

W jaki sposób uwierzytelniane i zarządzane są konta z najwyższym poziomem uprawnień?

Firma Atlassian ogranicza dostęp do personelu, który potrzebuje tego dostępu ze względu na swoją rolę i obowiązki. Wszystkie systemy warstwy 1 są zarządzane za pośrednictwem scentralizowanej usługi logowania jednokrotnego (SSO) oraz katalogu Atlassian. Użytkownicy otrzymują odpowiednie prawa dostępu w oparciu o te profile, sterowane za pomocą przepływu pracy z naszego systemu zarządzania HR. W przypadku dostępu do wszystkich systemów warstwy 1 firma Atlassian stosuje uwierzytelnianie wieloskładnikowe. Włączyliśmy usługę uwierzytelniania dwuskładnikowego w konsoli zarządzania usługą hipernadzorcy oraz w interfejsie API AWS, a także codzienny raport z audytu na temat wszystkich prób uzyskania dostępu do funkcji zarządzania usługą hipernadzorcy. Listy dostępu do konsoli zarządzania usługą hipernadzorcy oraz interfejsu API AWS są przeglądane co kwartał. Co 8 godzin przeprowadzamy również synchronizację naszego systemu HR i magazynu tożsamości.

6.04.01. (c)

W jaki sposób autoryzowane są najbardziej krytyczne decyzje (np. dotyczące jednoczesnego anulowania aprowizacji dużych bloków zasobów) — czy jest to autoryzacja pojedyncza czy podwójna i przez które role w organizacji jest wykonywana?

Firma Atlassian ogranicza dostęp do personelu, który potrzebuje tego dostępu ze względu na swoją rolę i obowiązki. Wszystkie systemy warstwy 1 są zarządzane za pośrednictwem scentralizowanej usługi logowania jednokrotnego (SSO) oraz katalogu Atlassian. Użytkownicy otrzymują odpowiednie prawa dostępu w oparciu o te profile, sterowane za pomocą przepływu pracy z naszego systemu zarządzania HR. W przypadku dostępu do wszystkich systemów warstwy 1 firma Atlassian stosuje uwierzytelnianie wieloskładnikowe. Włączyliśmy usługę uwierzytelniania dwuskładnikowego w konsoli zarządzania usługą hipernadzorcy oraz w interfejsie API AWS, a także codzienny raport z audytu na temat wszystkich prób uzyskania dostępu do funkcji zarządzania usługą hipernadzorcy. Listy dostępu do konsoli zarządzania usługą hipernadzorcy oraz interfejsu API AWS są przeglądane co kwartał. Co 8 godzin przeprowadzamy również synchronizację naszego systemu HR i magazynu tożsamości.

Stosowane są mechanizmy kontroli segregacji obowiązków w odniesieniu do naszych podstawowych produktów i obejmują one między innymi:

• Przeglądy kontroli dostępu
• Grupy zabezpieczeń zarządzane przez aplikację HR
• Zatwierdzenie zmiany / ocena przez współpracownika / wdrożenie (PRGB)
• Mechanizmy kontroli przepływów pracy

6.04.01. (d)

Czy istnieją role o wysokim poziomie uprawnień przypisane do tej samej osoby? Czy to przypisanie łamie zasady segregacji obowiązków lub zasady niezbędnych minimalnych uprawnień?

Firma Atlassian ogranicza dostęp do personelu, który potrzebuje tego dostępu ze względu na swoją rolę i obowiązki. Wszystkie systemy warstwy 1 są zarządzane za pośrednictwem scentralizowanej usługi logowania jednokrotnego (SSO) oraz katalogu Atlassian. Użytkownicy otrzymują odpowiednie prawa dostępu w oparciu o te profile, sterowane za pomocą przepływu pracy z naszego systemu zarządzania HR. W przypadku dostępu do wszystkich systemów warstwy 1 firma Atlassian stosuje uwierzytelnianie wieloskładnikowe. Włączyliśmy usługę uwierzytelniania dwuskładnikowego w konsoli zarządzania usługą hipernadzorcy oraz w interfejsie API AWS, a także codzienny raport z audytu na temat wszystkich prób uzyskania dostępu do funkcji zarządzania usługą hipernadzorcy. Listy dostępu do konsoli zarządzania usługą hipernadzorcy oraz interfejsu API AWS są przeglądane co kwartał. Co 8 godzin przeprowadzamy również synchronizację naszego systemu HR i magazynu tożsamości.

Stosowane są mechanizmy kontroli segregacji obowiązków w odniesieniu do naszych podstawowych produktów i obejmują one między innymi:

• Przeglądy kontroli dostępu
• Grupy zabezpieczeń zarządzane przez aplikację HR
• Zatwierdzenie zmiany / ocena przez współpracownika / wdrożenie (PRGB)
• Mechanizmy kontroli przepływów pracy

6.04.01. (e)

Czy używasz kontroli dostępu opartej na rolach (RBAC)? Czy przestrzegana jest zasada niezbędnych minimalnych uprawnień?

W Atlassian ustanowiono przepływ pracy łączący nasz system zarządzania HR z systemem aprowizacji dostępu. Stosujemy mechanizm kontroli dostępu oparty na rolach, wykorzystujący wstępnie zdefiniowane profile użytkowników. Wszystkie konta użytkowników muszą zostać zatwierdzone przez kierownictwo, zanim otrzymają dostęp do danych, aplikacji, infrastruktury lub składników sieci.

Firma Atlassian nakłada ograniczenia na personel, który potrzebuje dostępu do naszych systemów, aplikacji oraz infrastruktury, zgodnie z pełnioną rolą i zakresem obowiązków, stosując zasadę minimalnych wymaganych uprawnień, co uzyskujemy dzięki naszym procesom uwierzytelniania.

6.04.01. (f)

Jakie zmiany, jeśli w ogóle, są wprowadzone w uprawnieniach i rolach administratora, aby umożliwić nadzwyczajny dostęp w sytuacji awaryjnej?

Nasz globalny zespół wsparcia technicznego prowadzi konto na wszystkich hostowanych systemach i aplikacjach w celu zapewnienia konserwacji i wsparcia. Zespół wsparcia uzyskuje dostęp do hostowanych aplikacji oraz danych wyłącznie w celu monitorowania kondycji aplikacji oraz przeprowadzenia konserwacji systemu lub aplikacji, bądź na wniosek klienta przesłany za pośrednictwem naszego systemu wsparcia.

6.04.01. (g)

Czy istnieje rola „administratora” dla klienta? Przykładowo czy administrator klienta odgrywa rolę w dodawaniu nowych użytkowników (ale bez możliwości zmiany pamięci masowej)?

Atlassian oferuje klientom rolę „administratora organizacji”, który administruje użytkownikami i grupami produktów klienta. Aby uzyskać więcej informacji, zobacz: https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.02. (a)

Jakie kontrole tożsamości kont użytkowników są przeprowadzane podczas rejestracji? Czy przestrzegane są określone normy (np. Ramy interoperacyjności e-administracji)?

• Czy istnieją różne poziomy kontroli tożsamości zależnie od wymaganych zasobów?

Nowi pracownicy firmy Atlassian na całym świecie są zobowiązani do poddania się sprawdzeniu przeszłości. W przypadku pracowników podejmujących pracę w firmie Atlassian w wyniku przejęcia przeszłość sprawdza się po dacie przejęcia. Wszyscy nowi pracownicy i niezależni wykonawcy przechodzą sprawdzenie pod kątem karalności, sprawdza się również ich wykształcenie, historię zatrudnienia oraz sytuację kredytową, jeśli rola lub stanowisko tego wymagają. Kierownictwo wyższego szczebla oraz księgowi przechodzą pełne sprawdzenie przeszłości.

W Atlassian ustanowiono przepływ pracy łączący nasz system zarządzania HR z systemem aprowizacji dostępu. Stosujemy mechanizm kontroli dostępu oparty na rolach, wykorzystujący wstępnie zdefiniowane profile użytkowników. Wszystkie konta użytkowników muszą zostać zatwierdzone przez kierownictwo, zanim otrzymają dostęp do danych, aplikacji, infrastruktury lub składników sieci.

6.04.02. (b)

Jakie procesy są stosowane w celu anulowania aprowizacji danych uwierzytelniających?

Nasz proces anulowania aprowizacji obejmuje obecnie rozwiązanie stosunku pracy lub umowy. Użytkownicy, którzy zmieniają stanowisko wewnątrz organizacji, zazwyczaj zachowują swoje prawa dostępu, dzięki czemu mogą zachować zaangażowanie i korzystać ze wsparcia. Aby zgodnie z wartościami naszej firmy stworzyć wysoce responsywny i elastyczny zespół skoncentrowany na kliencie, skupiamy się na wykrywaniu nieautoryzowanego dostępu, a nie na jego ograniczaniu, co mogłoby spowolnić naszą reakcję.

6.04.02. (c)

Czy aprowizacja i anulowanie aprowizacji danych uwierzytelniających odbywa się jednocześnie w całym systemie chmurowym lub czy też istnieje ryzyko anulowania aprowizacji w wielu lokalizacjach geograficznych?

W Atlassian ustanowiono przepływ pracy łączący nasz system zarządzania HR z systemem aprowizacji dostępu. Stosujemy mechanizm kontroli dostępu oparty na rolach, wykorzystujący wstępnie zdefiniowane profile użytkowników. Wszystkie konta użytkowników muszą zostać zatwierdzone przez kierownictwo, zanim otrzymają dostęp do danych, aplikacji, infrastruktury lub składników sieci.

Nasza aplikacja HR jest synchronizowana z naszym wewnętrznym magazynem tożsamości co 8 godzin i wówczas następuje usunięcie wszelkich kont pracowników lub kontrahentów, którzy nie są już zatrudnieni.

6.04.03. (a)

Jakie mechanizmy kontroli przechowywania i ochrony danych mają zastosowanie do katalogu użytkowników (np. AD, LDAP) i dostępu do niego?

Dane są klasyfikowane i przetwarzane zgodnie z naszymi zasadami dotyczącymi bezpieczeństwa danych i cyklu życia informacji, a kontrole są wdrażane na tej podstawie. Więcej informacji można znaleźć na stronie: https://www.atlassian.com/trust/security/security-practices

Wszystkie systemy i projekty podlegają ocenie skutków, ponieważ są one związane z informacjami umożliwiającymi identyfikację osoby. Umowy firmy Atlassian ze stronami trzecimi zawierają w stosownych przypadkach zapisy dotyczące bezpieczeństwa i ochrony prywatności. Nowi dostawcy Atlassian są zobowiązani do wyrażenia zgody na zasady ochrony prywatności i bezpieczeństwa zawarte w naszych umowach.

Atlassian ma certyfikat ISO dla wielu produktów, co wymaga regularnych ocen ryzyka i przeglądów praktyk dotyczących danych.

Informacje o ocenie wpływu przekazywania danych można znaleźć na stronie: https://www.atlassian.com/legal/data-transfer-impact-assessment

Firma Atlassian przestrzega standardów dotyczących przechowywania i niszczenia danych, które określają, jak długo musimy zatrzymywać różnego rodzaju dane. Dane są klasyfikowane zgodnie z zasadami firmy Atlassian dotyczącymi bezpieczeństwa danych i cyklu życia informacji, a na tej podstawie wdrażane są środki kontroli.

W przypadku danych klienta w momencie rozwiązania umowy z firmą Atlassian dane należące do zespołu klienta zostaną usunięte z aktywnej produkcyjnej bazy danych, w wszystkie pliki załączników przekazane bezpośrednio do firmy Atlassian zostaną usunięte w ciągu 14 dni. Dane zespołu zostaną zachowane w zaszyfrowanych kopiach zapasowych przez 90 dni, a następnie zniszczone zgodnie z zasadami przechowywania danych firmy Atlassian. Jeśli w ciągu 90 dni od zażądania usunięcia danych konieczne okaże się przywrócenie bazy danych, zespół odpowiedzialny za eksploatację systemów ponownie usunie dane możliwie jak najszybciej po pełnym przywróceniu aktywnego systemu produkcyjnego. Więcej informacji można znaleźć pod adresem: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

6.04.03. (b)

Czy dane katalogu użytkowników są eksportowane w formacie interoperacyjnym?

Administratorzy mogą eksportować katalog użytkowników z poziomu panelu administracyjnego. Odpowiednie wskazówki są dostępne w witrynie wsparcia Atlassian: https://support.atlassian.com/organization-administration/docs/export-users-from-a-site/

6.04.03. (c)

Czy potrzeba informacji stanowi podstawę dostępu do danych klientów u dostawcy chmury?

Firma Atlassian ogranicza dostęp do personelu, który potrzebuje tego dostępu ze względu na swoją rolę i obowiązki. Wszystkie systemy warstwy 1 są zarządzane za pośrednictwem scentralizowanej usługi logowania jednokrotnego (SSO) oraz katalogu Atlassian. Użytkownicy otrzymują odpowiednie prawa dostępu w oparciu o te profile, sterowane za pomocą przepływu pracy z naszego systemu zarządzania HR. W przypadku dostępu do wszystkich systemów warstwy 1 firma Atlassian stosuje uwierzytelnianie wieloskładnikowe. Włączyliśmy usługę uwierzytelniania dwuskładnikowego w konsoli zarządzania usługą hipernadzorcy oraz w interfejsie API AWS, a także codzienny raport z audytu na temat wszystkich prób uzyskania dostępu do funkcji zarządzania usługą hipernadzorcy. Listy dostępu do konsoli zarządzania usługą hipernadzorcy oraz interfejsu API AWS są przeglądane co kwartał. Co 8 godzin przeprowadzamy również synchronizację naszego systemu HR i magazynu tożsamości.

Stosowane są mechanizmy kontroli segregacji obowiązków w odniesieniu do naszych podstawowych produktów i obejmują one między innymi:

• Przeglądy kontroli dostępu
• Grupy zabezpieczeń zarządzane przez aplikację HR
• Zatwierdzenie zmiany / ocena przez współpracownika / wdrożenie (PRGB)
• Mechanizmy kontroli przepływów pracy

6.04.04.

W przypadku kluczy pozostających pod kontrolą dostawcy chmury:

6.04.04. (a)

Czy istnieją kontrole zabezpieczeń dotyczące odczytu i zapisu tych kluczy? Przykładem są zasady silnych haseł, klucze przechowywane w oddzielnym systemie, sprzętowe moduły bezpieczeństwa (HSM) dla kluczy certyfikatów głównych, uwierzytelnianie oparte na karcie inteligentnej, bezpośredni ekranowany dostęp do pamięci masowej, krótki okres użytkowania kluczy itp.

Atlassian stosuje zasady szyfrowania i kryptografii oraz wytyczne dotyczące ich wdrażania. Niniejsza polityka jest corocznie weryfikowana i aktualizowana zgodnie z naszym programem zarządzania zasadami (Policy Management Program, PMP). Więcej informacji można znaleźć na stronie: https://www.atlassian.com/trust/security/security-management-program.

Atlassian stosuje udokumentowane procedury zarządzania kluczami dla naszej infrastruktury chmury. Klucze szyfrowania załączników Amazon, przechowywane w S3, są zarządzane przez Amazon KMS. Proces szyfrowania, zarządzania kluczami i deszyfrowania jest regularnie kontrolowany i weryfikowany wewnętrznie przez Amazon w ramach istniejącego procesu audytu. W przypadku istotnych zmian ról lub statusu zatrudnienia następuje rotacja kluczy zarządzanych przez Atlassian. Usługa AWS KMS spełnia wymagania SOC 1, SOC 2, SOC 3. Aby uzyskać więcej informacji, zobacz: https://aws.amazon.com/kms/

6.04.04. (b)

Czy istnieją kontrole zabezpieczeń dotyczące używania tych kluczy do podpisywania i szyfrowania danych?

Atlassian stosuje udokumentowane procedury zarządzania kluczami dla naszej infrastruktury chmury. Klucze szyfrowania załączników Amazon, przechowywane w S3, są zarządzane przez Amazon KMS. Proces szyfrowania, zarządzania kluczami i deszyfrowania jest regularnie kontrolowany i weryfikowany wewnętrznie przez Amazon w ramach istniejącego procesu audytu. Po utworzeniu klucze główne w KMS umożliwiają automatyczną rotację w celu generowania materiału klucza głównego co 365 dni (raz w roku).

6.04.04. (c)

Czy obowiązują procedury na wypadek naruszenia bezpieczeństwa kluczy (np. listy unieważniania kluczy)?

Atlassian stosuje udokumentowane procedury zarządzania kluczami w naszej infrastrukturze chmury. Przechowywane w S3 klucze szyfrowania załączników Amazon są zarządzane przez Amazon KMS. Proces szyfrowania, zarządzania kluczami i deszyfrowania jest regularnie kontrolowany i weryfikowany wewnętrznie przez Amazon w ramach istniejącego procesu audytu. W przypadku istotnych zmian ról lub statusu zatrudnienia następuje rotacja kluczy zarządzanych przez Atlassian. Usługa AWS KMS spełnia wymagania SOC 1, SOC 2, SOC 3. Więcej informacji można znaleźć na stronie https://aws.amazon.com/kms/.

6.04.04. (c)

Czy obowiązują procedury na wypadek naruszenia bezpieczeństwa kluczy (np. listy unieważniania kluczy)?

Atlassian stosuje udokumentowane procedury zarządzania kluczami w naszej infrastrukturze chmury. Przechowywane w S3 klucze szyfrowania załączników Amazon są zarządzane przez Amazon KMS. Proces szyfrowania, zarządzania kluczami i deszyfrowania jest regularnie kontrolowany i weryfikowany wewnętrznie przez Amazon w ramach istniejącego procesu audytu. W przypadku istotnych zmian ról lub statusu zatrudnienia następuje rotacja kluczy zarządzanych przez Atlassian. Usługa AWS KMS spełnia wymagania SOC 1, SOC 2, SOC 3. Więcej informacji można znaleźć na stronie https://aws.amazon.com/kms/.

6.04.04. (d)

Czy unieważnianie kluczy może rozwiązać problemy związane z ich jednoczesnym wykorzystywaniem w wielu lokalizacjach?

Atlassian stosuje udokumentowane procedury zarządzania kluczami w naszej infrastrukturze chmury. Przechowywane w S3 klucze szyfrowania załączników Amazon są zarządzane przez Amazon KMS. Proces szyfrowania, zarządzania kluczami i deszyfrowania jest regularnie kontrolowany i weryfikowany wewnętrznie przez Amazon w ramach istniejącego procesu audytu. W przypadku istotnych zmian ról lub statusu zatrudnienia następuje rotacja kluczy zarządzanych przez Atlassian. Usługa AWS KMS spełnia wymagania SOC 1, SOC 2, SOC 3. Więcej informacji można znaleźć na stronie https://aws.amazon.com/kms/.

6.04.04. (e)

Czy obrazy systemu klienta są chronione lub szyfrowane?

Firma Atlassian wykorzystuje standard branżowy Transport Layer Security („TLS”) w wersji 1.2 do utworzenia bezpiecznego połączenia przy użyciu 256-bitowego szyfrowania Advanced Encryption Standard („AES”). Dyski serwerowe, na których są przechowywane dane użytkowników, są szyfrowane w całości podczas magazynowania przy użyciu metody AES, która jest standardem branżowym. Dane dzierżawy są szyfrowane w bazach AWS RDS lub ich kopiach zapasowych, a także w magazynach pamięci do przechowywania długoterminowego (S3), podobnie jak wszystkie załączniki. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management.

Wszystkie dane klientów przechowywane w produktach i usługach Atlassian Cloud są szyfrowane w trakcie przesyłania przez sieci publiczne przy użyciu protokołu Transport Layer Security (TLS) 1.2+ z doskonałym utajnianiem z wyprzedzeniem (ang. Perfect Forward Secrecy, 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 są przechowywane dane klientów i załączniki z produktów Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie i Trello, są w całości szyfrowane podczas magazynowania przy użyciu będącej standardem branżowym metody AES-256.

W przypadku szyfrowania w trakcie magazynowania szyfrujemy w szczególności dane klientów przechowywane na dysku, takie jak dane zgłoszenia Jira (szczegóły, komentarze, załączniki) lub dane strony Confluence (zawartość strony, komentarze, załączniki). Szyfrowanie danych w trakcie magazynowania pomaga chronić przed nieautoryzowanym dostępem i zapewnia, że dostęp do danych mają tylko upoważnieni użytkownicy i usługi z kontrolowanym dostępem do kluczy szyfrowania.

6.04.05. (a)

Szyfrowanie można wykorzystywać w wielu miejscach – co ono obejmuje?

• Dane w trakcie przesyłania?
• Dane w trakcie magazynowania?
• Dane w procesorze lub pamięci?

Atlassian stosuje zasady szyfrowania i kryptografii oraz wytyczne dotyczące ich wdrażania. Niniejsza polityka jest corocznie weryfikowana i aktualizowana zgodnie z naszym programem zarządzania zasadami (Policy Management Program, PMP). Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/security/security-management-program.

Atlassian stosuje udokumentowane procedury zarządzania kluczami w naszej infrastrukturze chmury. Przechowywane w S3 klucze szyfrowania załączników Amazon są zarządzane przez Amazon KMS. Proces szyfrowania, zarządzania kluczami i deszyfrowania jest regularnie kontrolowany i weryfikowany wewnętrznie przez Amazon w ramach istniejącego procesu audytu. W przypadku istotnych zmian ról lub statusu zatrudnienia następuje rotacja kluczy zarządzanych przez Atlassian.

Wszystkie dane klientów przechowywane w produktach i usługach Atlassian Cloud są szyfrowane w trakcie przesyłania przez sieci publiczne przy użyciu protokołu Transport Layer Security (TLS) 1.2+ z doskonałym utajnianiem z wyprzedzeniem (ang. Perfect Forward Secrecy, 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 są przechowywane dane klientów i załączniki z produktów Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie i Trello, są w całości szyfrowane podczas magazynowania przy użyciu będącej standardem branżowym metody AES-256.

W przypadku szyfrowania w trakcie magazynowania szyfrujemy w szczególności dane klientów przechowywane na dysku, takie jak dane zgłoszenia Jira (szczegóły, komentarze, załączniki) lub dane strony Confluence (zawartość strony, komentarze, załączniki). Szyfrowanie danych w trakcie magazynowania pomaga chronić przed nieautoryzowanym dostępem i zapewnia, że dostęp do danych mają tylko upoważnieni użytkownicy i usługi z kontrolowanym dostępem do kluczy szyfrowania.

6.04.05. (b)

Czy wdrożono jasne zasady dotyczące tego, co powinno być szyfrowane, a co nie?

Atlassian stosuje zasady szyfrowania i kryptografii oraz wytyczne dotyczące ich wdrażania. Niniejsza polityka jest corocznie weryfikowana i aktualizowana zgodnie z naszym programem zarządzania zasadami (Policy Management Program, PMP). Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/security/security-management-program.

Atlassian stosuje udokumentowane procedury zarządzania kluczami w naszej infrastrukturze chmury. Przechowywane w S3 klucze szyfrowania załączników Amazon są zarządzane przez Amazon KMS. Proces szyfrowania, zarządzania kluczami i deszyfrowania jest regularnie kontrolowany i weryfikowany wewnętrznie przez Amazon w ramach istniejącego procesu audytu. W przypadku istotnych zmian ról lub statusu zatrudnienia następuje rotacja kluczy zarządzanych przez Atlassian.

6.04.05. (d)

Kto zarządza kluczami dostępu?

Do zarządzania kluczami Atlassian wykorzystuje usługę zarządzania kluczami AWS Key Management Service (KMS). 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.

6.04.05. (e)

W jaki sposób chronione są klucze?

Do zarządzania kluczami Atlassian wykorzystuje usługę zarządzania kluczami AWS Key Management Service (KMS). 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.

6.04.06. (a)

Jakie formy uwierzytelniania są stosowane w przypadku operacji wymagających wysokiego poziomu bezpieczeństwa? Mogą one obejmować logowanie do interfejsów zarządzania, tworzenie kluczy, dostęp do kont wielu użytkowników, konfigurację zapory, dostęp zdalny itp.

• Czy uwierzytelnianie dwuskładnikowe jest używane do zarządzania krytycznymi komponentami infrastruktury, takimi jak zapory?

Postępujemy zgodnie z wytycznymi określonymi w specjalnej publikacji NIST 800-63B. Więcej informacji: https://pages.nist.gov/800-63-3/sp800-63b.html.

Proces przydzielania haseł został opisany w Zasadach Atlassian dotyczących haseł. Nowe hasła nie będą przekazywane drogą elektroniczną, z wyjątkiem przypadków, w których wysyłane jest początkowe hasło jednorazowe. W takich przypadkach użytkownik musi zmienić jednorazowe hasło przy pierwszym użyciu.

Środki kontroli związane z kontrolą dostępu zostały szerzej omówione w Zasadach zarządzania uprawnieniami dostępu, których fragment można znaleźć na stronie https://www.atlassian.com/trust/security/ismp-policies.

Firma Atlassian nakłada ograniczenia na personel, który potrzebuje dostępu do naszych systemów, aplikacji oraz infrastruktury, zgodnie z pełnioną funkcją i zakresem obowiązków, stosując zasadę minimalnych wymaganych uprawnień, co uzyskujemy dzięki naszym procesom uwierzytelniania. Cały dostęp odbywa się za pośrednictwem uwierzytelnionych sesji i w oparciu o konkretne uprawnienia.

Firma Atlassian ogranicza dostęp do personelu, który potrzebuje tego dostępu ze względu na swoją rolę i obowiązki. Wszystkie systemy warstwy 1 są zarządzane za pośrednictwem scentralizowanej usługi logowania jednokrotnego (SSO) oraz katalogu Atlassian. Użytkownicy otrzymują odpowiednie prawa dostępu w oparciu o te profile, sterowane za pomocą przepływu pracy z naszego systemu zarządzania HR. W przypadku dostępu do wszystkich systemów warstwy 1 firma Atlassian stosuje uwierzytelnianie wieloskładnikowe. Włączyliśmy usługę uwierzytelniania dwuskładnikowego w konsoli zarządzania usługą hipernadzorcy oraz w interfejsie API AWS, a także codzienny raport z audytu na temat wszystkich prób uzyskania dostępu do funkcji zarządzania usługą hipernadzorcy. Listy dostępu do konsoli zarządzania usługą hipernadzorcy oraz interfejsu API AWS są przeglądane co kwartał. Co 8 godzin przeprowadzamy również synchronizację naszego systemu HR i magazynu tożsamości.

6.04.07. (a)

Czy zapewniacie funkcję wykrywania anomalii (możliwość wykrywania nietypowego i potencjalnie złośliwego ruchu IP oraz tego typu zachowań użytkowników lub zespołu wsparcia)? Na przykład analiza nieudanych i udanych logowań, nietypowych pór dnia, wielokrotnych logowań itp.

Bardzo niewielka część platformy Atlassian Cloud jest widoczna przez zapory. Dokonujemy regularnych przeglądów reguł zapory. Wdrożyliśmy technologię IDS w naszych biurach oraz naszym środowisku hostingu w chmurze. Przekazywanie dzienników związanych z platformą Atlassian Cloud jest zintegrowane z platformą analizy zabezpieczeń. Na poziomie kontenera platformy Cloud integralność plików jest zachowana, ponieważ instancje nie są możliwe do modyfikacji. Dział inżynierii sieci firmy Atlassian wykorzystuje technologie IPS wbudowane w nasze zapory, a ponadto wdrożyliśmy w naszych środowiskach biurowych i chmurowych technologie IDS. Funkcjonalności DDoS są dostarczane przez naszego dostawcę usług internetowych / operatora.

Dzienniki kluczowych systemów są przekazywane z każdego systemu do scentralizowanej platformy dzienników, gdzie są dostępne tylko do odczytu. Zespół ds. bezpieczeństwa Atlassian tworzy alerty na naszej platformie analizy zabezpieczeń (Splunk) i monitoruje wskaźniki pod kątem naruszeń. Nasze zespoły inżynierów ds. niezawodności lokalizacji (SRE) wykorzystują tę platformę do monitorowania problemów z dostępnością lub wydajnością. Dzienniki są przechowywane przez 30 dni w dynamicznej kopii zapasowej i przez 365 dni w kopii zapasowej offline.

6.04.07. (b)

Jakie zasady obowiązują w przypadku kradzieży danych uwierzytelniających klienta (wykrywanie, unieważnianie, dowody działań)?

W kontekście usług chmurowych Atlassian nasi klienci mogą być odpowiedzialni za niektóre lub wszystkie aspekty zarządzania dostępem użytkowników usług znajdujących się pod ich kontrolą.

W związku z tym Atlassian umożliwia naszym klientom zarządzanie dostępem użytkowników tych usług, na przykład poprzez zapewnienie uprawnień administracyjnych do zarządzania dostępem lub jego odebrania. Atlassian sprawdza również dane uwierzytelniające klientów pod kątem wycieków i wymusza aktualizowanie haseł.

Atlassian nie zapewnia ochrony przed wyciekami informacji (ang. Data Loss Prevention, DLP) bezpośrednio w ramach wdrożeń Cloud. Jednak na platformie Atlassian Marketplace można znaleźć dostawców, takich jak Nightfall, których usługi Atlassian poleca klientom potrzebującym funkcji DLP. Strona Nightfall na platformie Marketplace można znaleźć tutaj: https://marketplace.atlassian.com/vendors/1217783/nightfall. Nightfall oferuje automatyczne skanowanie poufnych informacji, w tym danych uwierzytelniających, sekretów i kluczy API.

Firma Atlassian uruchomiła rozwiązanie Beacon, które znajduje się obecnie w wersji beta i dodaje funkcje DLP. Dopóki Beacon nie wyjdzie z wersji beta, Atlassian nadal zaleca korzystanie z Nightfall. Więcej informacji na temat Atlassian Beacon można znaleźć na stronie https://www.atlassian.com/software/beacon.

Mamy udokumentowaną Politykę i Plan reagowania na incydenty dotyczące bezpieczeństwa, których najważniejsze zasady są następujące:

• Przewidywanie incydentów związanych z bezpieczeństwem i przygotowanie do zareagowania na incydent.
• Ograniczenie wpływu incydentów, eliminowanie ich i odzyskiwanie po ich wystąpieniu.
• Inwestowanie w naszych pracowników, procesy i technologie, aby móc pewnie wykrywać i analizować incydenty związane z bezpieczeństwem, jeśli się pojawią.
• Nadawanie ochronie danych osobowych oraz danych klientów najwyższego priorytetu w przypadku incydentów związanych z bezpieczeństwem.
• Regularne ćwiczenie procedury reagowania na incydenty związane z bezpieczeństwem.
• Wyciąganie wniosków z zarządzania incydentami związanymi z bezpieczeństwem i doskonalenie tego obszaru działalności.
• Informowanie kierownictwa Atlassian o krytycznych incydentach związanych z bezpieczeństwem.

6.04.08.

Poniższe pytania dotyczą systemów zarządzania tożsamością i dostępem, które są oferowane przez dostawcę chmury do użytku i kontroli przez korzystających z niej klientów.

6.04.08.01. (a)

Czy system umożliwia korzystanie z federacyjnej infrastruktury IDM, która jest interoperacyjna zarówno w przypadku systemów o wysokim poziomie bezpieczeństwa (systemów OTP, jeśli są wymagane), jak i tych o niskim poziomie bezpieczeństwa (np. korzystających z nazwy użytkownika i hasła)?

Atlassian Access obsługuje standardy federacji tożsamości w produktach Atlassian (Confluence, Jira, Jira Align, Bitbucket itp.). Atlassian Access może automatycznie synchronizować Active Directory z Atlassian za pomocą Okta, Azure AD lub OneLogin. Więcej informacji można znaleźć na stronie https://www.atlassian.com/enterprise/cloud/access. Konfiguracja SSO dla konkretnego produktu (Generic SAML v2.0, Google, Okta, OneLogin, PingIdentity, ADFS):

• Opsgenie obsługuje wielu dostawców SSO. Więcej informacji można znaleźć na stronie https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/.
• Trello obsługuje wielu dostawców SSO. Więcej informacji można znaleźć na stronie https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization.
• Statuspage obsługuje wielu dostawców SSO. Więcej informacji można znaleźć na stronie https://help.statuspage.io/knowledge_base/categories/single-sign-on-2.

6.04.08.01. (b)

Czy dostawca chmury współpracuje z zewnętrznymi dostawcami tożsamości?

Klienci Atlassian mogą skorzystać z usług wybranego przez siebie zewnętrznego dostawcy tożsamości, jeśli jest obsługiwany przez Atlassian. Strona wsparcia Atlassian zawiera szczegółowe informacje na temat tych funkcji i sposobów podłączania wybranego dostawcy tożsamości: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/.

6.04.08.01. (c)

Czy istnieje możliwość włączenia logowania jednokrotnego?

W większości produktów firma Atlassian obsługuje uwierzytelnianie przy użyciu tożsamości Google, Microsoft i Apple. Obsługujemy również protokół SAML w przypadku naszych usług chmurowych Atlassian za pośrednictwem Atlassian Access. Więcej informacji: https://www.atlassian.com/enterprise/cloud/access.

6.04.08.02. (a)

Czy system danych uwierzytelniających klienta pozwala na rozdzielenie ról i obowiązków oraz obsługę wielu domen (lub pojedynczego klucza dla wielu domen, ról i obowiązków)?

Atlassian to aplikacja SaaS z wielodostępem. Jedną z kluczowych cech rozwiązania Atlassian Cloud jest wielodostęp, który umożliwia wielu klientom współdzielenie jednej instancji warstwy aplikacji Jira lub Confluence, jednocześnie zapewniając odizolowanie danych aplikacji każdej dzierżawy. Atlassian Cloud realizuje to za pośrednictwem usługi TCS (Tenant Context Service). Każdy identyfikator użytkownika jest powiązany z dokładnie jedną dzierżawą, która następnie służy do uzyskania dostępu do aplikacji Atlassian Cloud. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/security/security-practices#tenant-isolation.

Klienci naszych planów Enterprise i Premium Cloud mają dostęp do centralnego panelu sterowania administracyjnego. Administratorzy organizacji mogą zarządzać dostępem i uprawnieniami użytkowników we wszystkich instancjach produktu. Zapoznaj się z naszym wpisem na blogu tutaj: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Atlassian oferuje klientom rolę „administratora organizacji”, który administruje użytkownikami i grupami produktów klienta. Więcej informacji można znaleźć na stronie https://support.atlassian.com/user-management/docs/give-users-admin-permissions/.

6.04.08.02. (b)

Jak zarządzacie dostępem do obrazów systemów klienta i jak zapewniacie, by nie znajdowały się w nich klucze uwierzytelniające i kryptograficzne?

Nasz globalny zespół wsparcia technicznego prowadzi konto na wszystkich hostowanych systemach i aplikacjach w celu zapewnienia konserwacji i wsparcia. Zespół wsparcia uzyskuje dostęp do hostowanych aplikacji oraz danych wyłącznie w celu monitorowania kondycji aplikacji oraz przeprowadzenia konserwacji systemu lub aplikacji, bądź na wniosek klienta przesłany za pośrednictwem naszego systemu wsparcia.

6.04.08.03. (a)

W jaki sposób dostawca usług chmurowych przedstawia się klientowi (czy odbywa się wzajemne uwierzytelnienie)?

• Kiedy klient wysyła polecenia interfejsu API?
• Kiedy klient loguje się do interfejsu zarządzania?

Aby przedstawić się klientowi, Atlassian wykorzystuje wzajemne uwierzytelnienie. Dokumentacja interfejsu API Atlassian jest dostępna na stronie https://developer.atlassian.com/cloud/. Atlassian Service Authentication Protocol (ASAP) to protokół uwierzytelnienia między usługami, który wykorzystuje token dostępu zaimplementowany przy użyciu tokena internetowego JSON (JWT) i podpisany przy użyciu kluczy RSA zaufanego urzędu Atlassian. Aby dowiedzieć się więcej, zapoznaj się z protokołem ASAP. Nie używamy tradycyjnych „Kont usług”, natomiast polegamy na uwierzytelnianiu i autoryzacji między usługami.

6.04.08.03. (b)

Czy jest obsługiwany federacyjny mechanizm uwierzytelniania?

Atlassian Access obsługuje standardy federacji tożsamości w produktach Atlassian (Confluence, Jira, Jira Align, Bitbucket itp.). Atlassian Access może automatycznie synchronizować Active Directory z Atlassian za pomocą Okta, Azure AD lub OneLogin. Więcej informacji można znaleźć na stronie https://www.atlassian.com/enterprise/cloud/access. Konfiguracja SSO dla konkretnego produktu (Generic SAML v2.0, Google, Okta, OneLogin, PingIdentity, ADFS):

• Opsgenie obsługuje wielu dostawców SSO. Więcej informacji można znaleźć na stronie https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/.
• Trello obsługuje wielu dostawców SSO. Więcej informacji można znaleźć na stronie https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization.
• Statuspage obsługuje wielu dostawców SSO. Więcej informacji można znaleźć na stronie https://help.statuspage.io/knowledge_base/categories/single-sign-on-2.

6.05.

Ważne jest zapewnienie, aby dostawca prowadził aktualną listę zasobów sprzętowych i oprogramowania (aplikacji) znajdujących się pod kontrolą dostawców usług chmurowych. Umożliwia to sprawdzenie, czy wszystkie systemy mają odpowiednie elementy kontrolne, i zapewnienie, że systemy nie mogą posłużyć jako „tylna furtka” do infrastruktury.

6.05. (a)

Czy dostawca posiada zautomatyzowany sposób inwentaryzacji wszystkich zasobów ułatwiający właściwe zarządzanie?

Nasze systemy produkcyjne są umieszczone w infrastrukturze udostępnianej przez dostawców usług w chmurze. Ze względu na charakter usługi systemy te nie są monitorowane na poziomie sprzętowym. Stanowiące ich podstawę mikrousługi, w oparciu o które działają nasze produkty, są monitorowane w niestandardowej bazie danych „Usługa”. Ta baza danych jest aktualizowana automatycznie po wdrożeniu usługi.

Nasz zespół ds. technologii w miejscu pracy prowadzi wykaz zasobów wszystkich punktów końcowych, wykorzystując do śledzenia nasze własne oprogramowanie Jira.

6.05. (b)

Czy istnieje lista zasobów, z których klient korzystał w określonym przedziale czasu?

Atlassian to aplikacja SaaS z wielodostępem. Wielodostęp jest jedną z kluczowych cech rozwiązania Atlassian Cloud i umożliwia wielu klientom współdzielenie jednej instancji warstwy aplikacji Jira lub Confluence, jednocześnie zapewniając odizolowanie danych aplikacji każdej dzierżawy. W rozwiązaniu Atlassian Cloud jest to realizowane przy użyciu usługi Tenant Context Service (TCS). Każdy identyfikator użytkownika jest powiązany z dokładnie jedną dzierżawą, która następnie służy do uzyskania dostępu do aplikacji Atlassian Cloud. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/security/security-practices#tenant-isolation

Poniższe pytania należy zadać, gdy klient końcowy wdraża dane, które wymagałyby dodatkowej ochrony (tj. uznane za wrażliwe).

6.05. (c)

Czy zasoby są klasyfikowane pod względem wrażliwości i krytyczności?

• Jeśli tak, to czy dostawca stosuje odpowiednią segregację między systemami o różnych klasyfikacjach i dla jednego klienta posiadającego systemy z różnymi klasyfikacjami bezpieczeństwa?

Atlassian stosuje 4-poziomową ocenę naszych zasobów i usług, a dla każdego poziomu są określone wymagania dotyczące czasu pracy, poziomu usług i ciągłości. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/security/data-management.

6.06.

Ten zestaw pytań należy rozważyć, aby poznać ryzyko związane z uzależnieniem od dostawcy.

6.06. (a)

Czy istnieją udokumentowane procedury i interfejsy API do eksportowania danych z chmury?

Dane klientów są dostępne za pośrednictwem aplikacji internetowej oraz interfejsu API. Szczegółowe informacje o konkretnych produktach znajdują się poniżej.

• Confluence, Jira, Jira Align: szczegółowe informacje o naszym interfejsie API Atlassian można znaleźć na stronie https://developer.atlassian.com/cloud/jira/platform/rest/v3/
• Trello: dane tablicy są dostępne do eksportu przez członków tablicy w formacie JSON za pośrednictwem interfejsu API Trello REST. Pliki załączników można pobrać pojedynczo bezpośrednio z usługi Amazon S3 przy użyciu unikatowego hiperłącza do pliku. W wersji Trello Business Class i Enterprise oferowany jest uproszczony proces eksportu danych w odniesieniu do wszystkich danych organizacji i załączników. W przypadku każdej organizacji Business Class i Enterprise możliwy jest eksport wszystkich tablic jednym kliknięciem. Do pliku eksportu mogą być opcjonalnie dołączone pliki załączników przesłane bezpośrednio do Trello. Dane każdej eksportowanej tablicy są w formacie JSON i CSV (wartości oddzielone przecinkami).
• Opsgenie: interfejs API można znaleźć na stronie https://docs.opsgenie.com/docs/api-overview
• Statuspage: interfejs API można znaleźć na stronie https://doers.statuspage.io/api/v1/
• Bitbucket: do celów interoperacyjności z rozwiązania Bitbucket można pobrać lub eksportować dowolne kody źródłowe lub repozytoria. Więcej informacji: https://confluence.atlassian.com/bitbucket/does-bitbucket-backup-my-repositories-288658413.html
• Halp: dostępna jest funkcja eksportu w formacie CSV. Więcej dokumentacji można znaleźć na stronie https://plz.halp.com/article/5790zlyrun-export-to-csv

6.06. (b)

Czy w przypadku wszystkich danych przechowywanych w chmurze dostawca zapewnia interoperacyjne formaty eksportu?

Atlassian ułatwia realizację wniosków klientów o eksport danych przechowywanych w produktach Atlassian. Do eksportowania danych produktów i użytkowników dostępne są wydajne narzędzia do przenoszenia danych i zarządzania nimi. Aby dowiedzieć się więcej na temat eksportu danych z Atlassian Cloud, zapoznaj się z naszą dokumentacją dotyczącą importu i eksportu: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Więcej informacji na temat eksportowania danych w popularnych formatach, takich jak CSV, HTML i XML: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/.

6.06. (c)

Czy interfejsy API stosowane w modelu SaaS są ustandaryzowane?

Szczegółowe informacje na temat naszych interfejsów API Atlassian Cloud można znaleźć na stronie https://developer.atlassian.com/explore-the-apis/

Szczegółowe informacje o interfejsie API do konkretnego produktu:

• Trello: dokumentacja interfejsu API jest dostępna na stronie https://developer.atlassian.com/cloud/trello
• Jira Align: interfejs API można znaleźć na stronie https://help.jiraalign.com/hc/en-us/articles/360045371954-Getting-started-with-the-REST-API-2-0
• Statuspage: interfejs API można znaleźć na stronie https://doers.statuspage.io/api/v1
• Opsgenie: interfejs API można znaleźć na stronie https://docs.opsgenie.com/docs/api-overview
• Halp: obecnie nie ma publicznego interfejsu API.

6.06. (d)

Czy są dostępne funkcje eksportowania aplikacji utworzonych przez użytkownika w standardowym formacie?

Nie ma to zastosowania, ponieważ Atlassian obsługuje model SaaS (oprogramowanie jako usługa).

6.06. (e)

Czy istnieją procesy umożliwiające sprawdzenie, czy dane można eksportować do innego dostawcy usług chmurowych — na przykład w sytuacji, gdy klient chce zmienić dostawcę?

Atlassian ułatwia realizację wniosków klientów o eksport danych przechowywanych w produktach Atlassian. Do eksportowania danych produktów i użytkowników dostępne są wydajne narzędzia do przenoszenia danych i zarządzania nimi. Aby dowiedzieć się więcej na temat eksportu danych z Atlassian Cloud, zapoznaj się z naszą dokumentacją dotyczącą importu i eksportu: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Więcej informacji na temat eksportowania danych w popularnych formatach, takich jak CSV, HTML i XML: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/.

6.06. (f)

Czy klient może samodzielnie wyodrębnić dane, aby sprawdzić, czy ich format jest uniwersalny i pozwala na przeniesienie danych do innego dostawcy usług chmurowych?

Atlassian ułatwia realizację wniosków klientów o eksport danych przechowywanych w produktach Atlassian. Do eksportowania danych produktów i użytkowników dostępne są wydajne narzędzia do przenoszenia danych i zarządzania nimi. Aby dowiedzieć się więcej na temat eksportu danych z Atlassian Cloud, zapoznaj się z naszą dokumentacją dotyczącą importu i eksportu: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Więcej informacji na temat eksportowania danych w popularnych formatach, takich jak CSV, HTML i XML: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/.

6.07.

Zapewnienie ciągłości jest ważne dla organizacji. Można wprawdzie zawrzeć umowy o poziomie usług określające minimalny czas dostępności systemów, jednak pozostaje szereg innych kwestii.

6.07. (a)

Czy dostawca stosuje udokumentowaną metodę zapewniającą szczegółowy opis wpływu zakłócenia?

• Jakie są następujące parametry usług: docelowy punkt odzyskiwania (RPO) i docelowy czas odzyskiwania (RTO)? Należy podać szczegółowe informacje według poziomu krytyczności usługi.
• Czy w procesie przywracania są odpowiednio uwzględnione działania związane z bezpieczeństwem informacji?
• Jakie są kanały komunikacji z klientami końcowymi w razie zakłócenia działania?
• Czy wyraźnie określono role i obowiązki zespołów w trakcie postępowania z zakłóceniami?

Obowiązuje polityka Zachowanie ciągłości działania i odzyskiwanie awaryjne oraz Plan zachowania ciągłości działania i odzyskiwania awaryjnego. Są one co roku poddawane przeglądowi przez komitet sterujący ds. zachowania ciągłości działania / odzyskiwania awaryjnego. Więcej informacji (w tym na temat wskaźników RPO i RTO oraz odporności opartej na wykorzystaniu stref dostępności) można znaleźć na stronie https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management oraz https://www.atlassian.com/trust/security/data-management.

Nasze partnerskie centra danych mają wiele certyfikatów zgodności. Te certyfikaty dotyczą bezpieczeństwa fizycznego, 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. Informacje na temat zapewniania bezpieczeństwa fizycznego AWS można znaleźć na stronie http://aws.amazon.com/compliance/

6.07. (b)

Czy dostawca określił kategorie priorytetu odzyskiwania i jaki byłby nasz (klienta końcowego) względny priorytet przywracania? Uwaga: może to być kategoria (WYSOKI/ŚREDNI/NISKI).

Wszyscy właściciele systemów, procesów lub usług o znaczeniu krytycznym zapewniają odpowiednią ciągłość działania i/lub odzyskiwanie awaryjne (BCDR) na poziomie odpowiadającym tolerancji na zakłócenia w razie awarii. Plany BCDR są testowane co kwartał, a wszelkie zidentyfikowane problemy są rozwiązywane. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management oraz https://www.atlassian.com/trust/security/data-management.

6.07. (c)

Jakie są zależności istotne dla procesu przywracania? Należy uwzględnić dostawców i partnerów w ramach outsourcingu.

Atlassian ma procedurę i dziennik działań związanych z przywracaniem danych. Na wysokim poziomie są one przewidziane w naszym wewnętrznym „Standardzie tworzenia kopii zapasowych” oraz w polityce „Zachowanie ciągłości działania i odzyskiwanie awaryjne”. W odniesieniu do każdej usługi Atlassian mamy jednak różne dokumenty wewnętrzne, które obejmują wykazy procedur, harmonogramy i procedury przywracania zainicjowanego przez klienta oraz przywracania zainicjowanego przez firmę Atlassian.

6.07. (d)

Jaka jest minimalna separacja w przypadku lokalizacji dodatkowej, gdy lokalizacja podstawowa przestanie być dostępna?

Nasze partnerskie centra danych mają wiele certyfikatów zgodności. Te certyfikaty dotyczą bezpieczeństwa fizycznego, 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. Informacje na temat zapewniania bezpieczeństwa fizycznego AWS można znaleźć pod adresem: http://aws.amazon.com/compliance/

6.07.01.

Zarządzanie incydentami i reagowanie na nie jest częścią zarządzania ciągłością działania. Celem tego procesu jest ograniczenie wpływu nieoczekiwanych i potencjalnie zakłócających zdarzeń do poziomu akceptowalnego dla organizacji. Aby ocenić, na ile organizacja potrafi ograniczyć do minimum prawdopodobieństwo wystąpienia incydentu dotyczącego bezpieczeństwa informacji lub zmniejszyć jego negatywny wpływ, należy zadać dostawcy usług chmurowych następujące pytania:

6.07.01. (a)

Czy dostawca ma formalny proces wykrywania, identyfikacji i analizowania incydentów oraz reagowania na nie?

Mamy udokumentowane Politykę i Plan reagowania na incydenty dotyczące bezpieczeństwa, których najważniejsze zasady są następujące:

• Przewidywanie incydentów związanych z bezpieczeństwem i przygotowanie do zareagowania na incydent.
• Ograniczenie wpływu incydentów, eliminowanie ich i odzyskiwanie po ich wystąpieniu.
• Inwestowanie w naszych pracowników, procesy i technologie, aby móc pewnie wykrywać i analizować incydenty związane z bezpieczeństwem, jeśli się pojawią.
• Nadawanie ochronie danych osobowych oraz danych klientów najwyższego priorytetu w przypadku incydentów związanych z bezpieczeństwem.
• Regularne ćwiczenie procedury reagowania na incydenty związane z bezpieczeństwem.
• Wyciąganie wniosków z zarządzania incydentami związanymi z bezpieczeństwem i doskonalenie tego obszaru działalności.
• Informowanie kierownictwa Atlassian o krytycznych incydentach związanych z bezpieczeństwem.


Zgodnie z tą polityką Atlassian utrzymuje plan reagowania na incydenty związane z bezpieczeństwem. Więcej informacji o naszym procesie reagowania na incydenty dotyczące bezpieczeństwa można znaleźć na stronie https://www.atlassian.com/trust/security/security-incident-management

Dzienniki kluczowych systemów są przekazywane dalej z każdego systemu do scentralizowanej platformy dzienników, gdzie są one dostępne tylko do odczytu. Zespół ds. bezpieczeństwa Atlassian tworzy alerty na naszej platformie analizy zabezpieczeń (Splunk) i monitoruje wskaźniki pod kątem naruszeń. Nasze zespoły inżynierów ds. niezawodności lokalizacji (SRE) wykorzystują tę platformę do monitorowania problemów z dostępnością lub wydajnością. Dzienniki są przechowywane przez 30 dni w dynamicznej kopii zapasowej i przez 365 dni w kopii zapasowej offline.

Więcej informacji na temat naszego programu detekcji można znaleźć na stronie https://www.atlassian.com/trust/security/detections-program.

6.07.01. (b)

Czy ten proces jest ćwiczony w celu sprawdzenia skuteczności procesów postępowania z incydentami? Czy podczas próby dostawca zapewnia również, aby wszyscy pracownicy działu wsparcia dostawcy usług chmurowych znali proces i swoje role podczas reagowania na incydenty (zarówno podczas incydentu, jak i w trakcie analizy po jego zakończeniu)?

W przypadku naszych usług Atlassian Cloud plany zachowania ciągłości działania i odzyskiwania awaryjnego są testowane co najmniej raz na kwartał. Dostępność w wielu regionach jest monitorowana w czasie rzeczywistym. Automatyczne testy awaryjnego przełączania regionów są przeprowadzane co tydzień w środowisku przedprodukcyjnym. Automatyczne testy przywracania danych konfiguracyjnych są wykonywane codziennie w środowisku produkcyjnym. W przypadku wszystkich usług Atlassian co kwartał przeprowadza się test odporności strefy dostępności w środowisku przedprodukcyjnym. Więcej informacji na temat naszego programu zachowania ciągłości działania można znaleźć na stronie https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

Nasze plany odzyskiwania awaryjnego są testowane i zatwierdzane przez zewnętrznych audytorów w ramach naszego programu zapewnienia zgodności. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/compliance/resources

Nasz plan reagowania na incydenty związane z bezpieczeństwem ćwiczymy, podejmując w czasie rzeczywistym działania w ramach reagowania na incydenty. Stosujemy podejście ukierunkowane na ciągłe doskonalenie w celu optymalizacji naszych możliwości reagowania.

Po zareagowaniu na incydent o wysokim poziomie ważności 1 lub 2 pierwotne zgłoszenie incydentu zostaje zamknięte i rozpoczyna się proces przeglądu po incydencie (PIR). W przypadku incydentów o wysokim poziomie ważności zespół ds. bezpieczeństwa przeprowadza analizę przyczyn pierwotnych i proponuje potencjalne ulepszenia dotyczące systemu i/lub rozwiązania problemu.

6.07.01. (c)

Jak wyglądają możliwości wykrywania?

• W jaki sposób klient korzystający z chmury może zgłaszać dostawcy nieprawidłowości i zdarzenia związane z bezpieczeństwem?
• Jakie udogodnienia zapewnia dostawca w przypadku zewnętrznych usług RTSM wybranych przez klienta, aby umożliwić ingerencję w swoje systemy (w stosownych przypadkach) lub skoordynowanie działań w ramach reagowania na incydenty z dostawcą usług w chmurze?
• Czy wykorzystywana jest usługa monitorowania bezpieczeństwa w czasie rzeczywistym (RTSM)? Czy usługę tę świadczy firma zewnętrzna? Jakie parametry i usługi są monitorowane?
• Czy przekazywany jest (na żądanie) okresowy raport o incydentach związanych z bezpieczeństwem (np. zgodnie z definicją ITIL)?
• Jak długo przechowywane są dzienniki dotyczące bezpieczeństwa? Czy dzienniki te są przechowywane w sposób bezpieczny? Kto ma dostęp do dzienników?
• Czy klient może tworzyć systemy HIPS/HIDS w obrazie maszyny wirtualnej? Czy istnieje możliwość zintegrowania informacji gromadzonych przez systemy klienta przeznaczone do wykrywania włamań i zapobiegania włamaniom z usługą RTSM dostawcy usług w chmurze lub firmy zewnętrznej?

Bardzo niewielka powierzchnia naszej platformy Atlassian Cloud jest widoczna przez zapory. Dokonujemy regularnych przeglądów reguł zapory. Wdrożyliśmy technologię IDS w naszych biurach oraz naszym środowisku hostingu w chmurze. Przekazywanie dzienników związanych z platformą Atlassian Cloud jest zintegrowane z platformą analizy zabezpieczeń. Na poziomie kontenera platformy Cloud integralność plików jest zachowana, ponieważ instancje nie są możliwe do modyfikacji. Dział inżynierii sieci firmy Atlassian wykorzystuje technologie IPS wbudowane w nasze zapory, a ponadto wdrożyliśmy w naszych środowiskach biurowych i chmurowych technologie IDS. Funkcjonalności DDoS są dostarczane przez naszego dostawcę usług internetowych/operatora. Więcej informacji na temat naszego programu wykrywania można znaleźć pod adresem: https://www.atlassian.com/trust/security/detections-program. Dzienniki kluczowych systemów są przekazywane z każdego systemu do scentralizowanej platformy dzienników, gdzie są dostępne tylko do odczytu. Zespół ds. bezpieczeństwa Atlassian tworzy alerty na naszej platformie analizy zabezpieczeń (Splunk) i monitoruje wskaźniki pod kątem naruszeń. Nasze zespoły inżynierów ds. niezawodności lokalizacji (SRE) wykorzystują tę platformę do monitorowania problemów z dostępnością lub wydajnością. Dzienniki są przechowywane przez 30 dni w dynamicznej kopii zapasowej i przez 365 dni w kopii zapasowej offline. Atlassian ogranicza możliwość przeglądania i odczytywania dzienników audytu do upoważnionego personelu na naszej scentralizowanej platformie do rejestrowania dzienników. Atlassian obsługuje również zewnętrzne kanały zgłaszania, za pośrednictwem których mogą napływać do nas informacje o lukach w zabezpieczeniach i incydentach, takie jak nasz program wykrywania błędów Bug Bounty, portal wsparcia dla klientów czy specjalne skrzynki e-mailowe i numery telefonów. Firma Atlassian zachęca klientów do zgłaszania przypadków nieautoryzowanego dostępu lub złośliwego zachowania. Więcej informacji można znaleźć pod adresem https://www.atlassian.com/trust/security/security-incident-management i https://www.atlassian.com/trust/security/security-incident-responsibilities.

6.07.01. (d)

Jak definiuje się poziomy ważności?

Atlassian wykorzystuje Common Vulnerability Scoring System (CVSS) jako metodę oceny ryzyka związanego z zabezpieczeniami i ustalania priorytetu dla każdej wykrytej luki. Atlassian stosuje następujące poziomy bezpieczeństwa oparte na samodzielnie wyliczonym wyniku CVSS:

• krytyczny,
• wysoki,
• średni,
• niski.


Szczegółowe informacje z uwzględnieniem zakresów wyników poszczególnych poziomów ważności można znaleźć na stronie: https://www.atlassian.com/trust/security/security-severity-levels.

6.07.01. (e)

Jak definiuje się procedury eskalacji? Na jakim etapie (jeśli w ogóle) angażowany jest klient korzystający z chmury?

Mamy udokumentowane Politykę i Plan reagowania na incydenty dotyczące bezpieczeństwa, których najważniejsze zasady są następujące:

• Przewidywanie incydentów związanych z bezpieczeństwem i przygotowanie do zareagowania na incydent.
• Ograniczenie wpływu incydentów, eliminowanie ich i odzyskiwanie po ich wystąpieniu.
• Inwestowanie w naszych pracowników, procesy i technologie, aby móc pewnie wykrywać i analizować incydenty związane z bezpieczeństwem, jeśli się pojawią.
• Nadawanie ochronie danych osobowych oraz danych klientów najwyższego priorytetu w przypadku incydentów związanych z bezpieczeństwem.
• Regularne ćwiczenie procedury reagowania na incydenty związane z bezpieczeństwem.
• Wyciąganie wniosków z zarządzania incydentami związanymi z bezpieczeństwem i doskonalenie tego obszaru działalności.
• Informowanie kierownictwa Atlassian o krytycznych incydentach związanych z bezpieczeństwem.


Zgodnie z tą polityką Atlassian utrzymuje plan reagowania na incydenty związane z bezpieczeństwem. Więcej informacji o naszym procesie reagowania na incydenty dotyczące bezpieczeństwa można znaleźć na stronie: https://www.atlassian.com/trust/security/security-incident-management

W Atlassian rozumiemy, jak ważne jest dla użytkowników, aby niezwłocznie otrzymywać powiadomienia o każdym naruszeniu danych. Dlatego stworzyliśmy rozbudowany interdyscyplinarny zespół i proces obsługi incydentów związanych z bezpieczeństwem, co zostało opisane na stronie: https://www.atlassian.com/trust/security/security-incident-management

Atlassian ma duże doświadczenie w zakresie terminowego i proaktywnego powiadamiania o incydentach oraz współpracy z naszymi klientami w sprawie wszelkich niezbędnych środków zaradczych.

72-godzinna oś czasu jest niedopuszczalna, ponieważ w całym procesie krytyczne znaczenie ma, aby od razu po wystąpieniu incydentu zespoły Atlassian reagujące na incydenty związane z bezpieczeństwem skoncentrowały się na sklasyfikowaniu i zminimalizowaniu skutków incydentu. Zamiast tego przekazujemy klientom powiadomienie „bez zbędnej zwłoki”, co jest zgodne z wymogiem prawnym przewidzianym w rozporządzeniu RODO w odniesieniu do podmiotów przetwarzających dane i zaspokaja wymogi prawne większości naszych klientów.

Incydenty bywają różne: od bardzo prostych do niezwykle złożonych, dlatego choć jesteśmy w stanie spełnić wymagania przewidziane prawem, nie możemy przyjąć uniwersalnej osi czasu dla wszystkich przypadków.

6.07.01. (f)

W jaki sposób dokumentuje się incydenty i gromadzi dowody?

Zgłoszenia Jira są tworzone w celu śledzenia i naprawiania błędów, a terminy ustala się zgodnie z naszymi poziomami SLO, z uwzględnieniem zarówno ważności, jak i źródła luki w zabezpieczeniach. Prowadzimy ciągły proces tworzenia zgłoszeń dotyczących rozpoznanych luk w zabezpieczeniach kierowanych do właścicieli systemów, a nasz zespół ds. zarządzania bezpieczeństwem sprawdza każdą zgłoszoną lukę w zabezpieczeniach i dba o podjęcie stosownych działań zaradczych.

Po rozwiązaniu incydentu o wysokim poziomie ważności 1 lub 2 pierwotne zgłoszenie incydentu zostaje zamknięte i rozpoczyna się proces przeglądu po incydencie (PIR). W przypadku incydentów o wysokim poziomie ważności zespół ds. bezpieczeństwa przeprowadza analizę głównych przyczyn i proponuje potencjalne ulepszenia dotyczące systemu i/lub rozwiązania problemu.

6.07.01. (g)

Jakie inne środki, oprócz uwierzytelniania, ewidencjonowania aktywności i audytu, stosuje się, aby zapobiegać złośliwej aktywności wewnątrz firmy lub minimalizować jej skutki?

Firma Atlassian wdrożyła technologię IDS w swoich biurach oraz swoim środowisku hostingu w chmurze. Przekazywanie dzienników jest zintegrowane z platformą do analizy bezpieczeństwa dedykowaną platformie Atlassian Cloud. Dzienniki kluczowych systemów są przekazywane z każdego systemu do scentralizowanej platformy dzienników, gdzie są dostępne tylko do odczytu. Zespół ds. bezpieczeństwa Atlassian tworzy alerty na naszej platformie analizy zabezpieczeń (Splunk) i monitoruje wskaźniki pod kątem naruszeń. Więcej informacji na temat naszego programu wykrywania można znaleźć pod adresem: https://www.atlassian.com/trust/security/detections-program.

6.07.01. (h)

Czy dostawca gromadzi wskaźniki dotyczące incydentów (tj. dane na temat liczby wykrytych lub zgłoszonych incydentów na miesiąc, liczby incydentów spowodowanych przez podwykonawców dostawcy usług w chmurze oraz całkowitej liczby takich incydentów, średniego czasu reakcji i rozwiązania itp.)?

• Które z tych danych dostawca udostępnia publicznie (uwaga: nie wszystkie dane dotyczące zgłaszanych incydentów mogą zostać upublicznione, ponieważ mogą one naruszać poufność klienta i ujawniać krytyczne informacje dotyczące bezpieczeństwa)?

Obecnie nie upubliczniamy naszych wewnętrznych wskaźników, ale udostępniamy działania po incydentach w przypadku incydentów operacyjnych o poziomach ważności 0 i 1 na naszej stronie Statuspage pod adresem: https://status.atlassian.com/.

6.07.01. (j)

Jak często dostawca testuje plany odzyskiwania awaryjnego i ciągłości działalności biznesowej?

W przypadku naszych usług Atlassian Cloud plany ciągłości działalności biznesowej i odzyskiwania awaryjnego są testowane co najmniej raz na kwartał. Dostępność w wielu regionach jest monitorowana w czasie rzeczywistym. Automatyczne testy pracy w trybie awaryjnym na poziomie regionalnym są przeprowadzane co tydzień w środowisku przedprodukcyjnym. Automatyczne testy przywracania danych konfiguracyjnych są wykonywane codziennie w środowisku produkcyjnym. W przypadku wszystkich usług Atlassian co kwartał przeprowadza się test odporności strefy dostępności w środowisku przedprodukcyjnym. Więcej informacji na temat naszego programu ciągłości działania można znaleźć na stronie: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

Plany odzyskiwania awaryjnego są testowane i zatwierdzane przez zewnętrznych audytorów w ramach naszego programu zapewnienia zgodności. Więcej informacji można znaleźć na stronie: https://www.atlassian.com/trust/compliance/resources

6.07.01. (k)

Czy dostawca gromadzi dane dotyczące poziomu zadowolenia z umów SLA?

Monitorujemy wszystkie instancje Cloud pod kątem wydajności i dostępności, ale obecnie nie oferujemy formalnej umowy SLA w zakresie dostępności aplikacji. Nasz zespół wsparcia oferuje umowę SLA dotyczącą początkowego czasu odpowiedzi i choć nie mamy umów SLA dotyczących rozwiązywania problemów w ramach wsparcia, dążymy do rozwiązania wszystkich przypisanych przypadków w ciągu 48 godzin. Atlassian udostępnia statystyki dotyczące najnowszych danych na temat statusu systemów Cloud na stronie: https://status.atlassian.com.

Jeśli zdecydujesz się skorzystać z naszej oferty Premium lub Enterprise, umowa SLA będzie zawierać konkretne gwarancje.

6.07.01. (l)

Czy dostawca przeprowadza testy pomocy technicznej? Przykładowo:

• Testy z podszywaniem się pod inną osobę (czy osoba na linii żądająca zresetowania hasła faktycznie jest tym, za kogo się podaje), czyli ataki z użyciem socjotechniki.

Atlassian zapewnia szkolenia z zakresu bezpieczeństwa informatycznego jako element szkolenia onboardingowego („Dzień 1”) dla nowych pracowników, a także ich ciągłość dla wszystkich pracowników.

Oprócz tego ogólnego szkolenia dotyczącego bezpieczeństwa informatycznego, nasi programiści przechodzą bardziej specjalistyczne szkolenie na temat bezpiecznego tworzenia kodu wspierane przez nasz zintegrowany program prowadzony przez inżynierów bezpieczeństwa.

Prowadzimy również ciągłe szkolenia tematyczne na temat złośliwego oprogramowania, phishingu oraz innych zagadnień związanych z bezpieczeństwem. https://www.atlassian.com/trust/security/security-practices#security-awareness-training

Prowadzimy formalną dokumentację ukończenia wewnętrznego szkolenia personelu. Pracownicy są zobowiązani do zaakceptowania Kodeksu postępowania i potwierdzania zgody co roku. Zasady te są dostępne dla wszystkich pracowników. Wymogi dotyczące świadomości bezpieczeństwa, poufności i prywatności są prezentowane podczas szkoleń pierwszego dnia i są dostępne dla wszystkich pracowników w Confluence.

6.07.01. (m)

Czy dostawca przeprowadza testy penetracyjne? Jak często? Jakie elementy faktycznie testuje się podczas testu penetracyjnego? Czy na przykład testuje się odizolowanie każdego obrazu dla celów bezpieczeństwa, aby sprawdzić, czy nie ma ryzyka „włamania się” z jednego obrazu do drugiego, a także uzyskania dostępu do infrastruktury hosta? Testy powinny również sprawdzić, czy możliwe jest uzyskanie za pośrednictwem wirtualnego obrazu dostępu do systemów zarządzania i wsparcia dostawców usług w chmurze (np. systemów aprowizacji i administracyjnej kontroli dostępu).

Prowadzimy wewnętrzny program Red Team, w ramach którego przeprowadzane są ciągłe testy penetracyjne całej naszej infrastruktury, usług chmurowych i osób.

Angażujemy zewnętrzne firmy konsultingowe w celu przeprowadzania corocznych testów penetracyjnych aplikacji skierowanych na zewnątrz. Testy te uzupełniamy również o mniejsze, ciągłe testy bezpieczeństwa przeprowadzane przez nasz zespół ds. testowania bezpieczeństwa wewnętrznego. Pisma potwierdzające przeprowadzanie tych testów penetracyjnych wraz z informacjami na temat procedury testowania oraz naszego podejścia do zewnętrznych testów bezpieczeństwa można znaleźć tutaj: https://www.atlassian.com/trust/security/security-testing.

6.07.01. (n)

Czy dostawca przeprowadza testy pod kątem luk w zabezpieczeniach? Jak często?

Zespół ds. bezpieczeństwa Atlassian stale skanuje infrastrukturę wewnętrzną i zewnętrzną pod kątem luk w zabezpieczeniach sieciowych, wykorzystując uznawany w branży skaner do wykrywania takich luk. Więcej informacji na temat programu zarządzania lukami w zabezpieczeniach można znaleźć na stronie: https://www.atlassian.com/trust/security/vulnerability-management.

6.07.01. (o)

Jak wygląda proces usuwania luk w zabezpieczeniach (bieżące poprawki, zmiana konfiguracji, aktualizacja do nowszej wersji oprogramowania itp.)?

Zgłoszenia Jira są tworzone w celu śledzenia i naprawiania błędów, a terminy ustala się zgodnie z naszymi poziomami SLO, z uwzględnieniem zarówno ważności, jak i źródła luki w zabezpieczeniach. Prowadzimy ciągły proces tworzenia zgłoszeń dotyczących rozpoznanych luk w zabezpieczeniach kierowanych do właścicieli systemów, a nasz zespół ds. zarządzania bezpieczeństwem sprawdza każdą zgłoszoną lukę w zabezpieczeniach i dba o podjęcie stosownych działań zaradczych.

Szczegółowe informacje na temat naszego programu zarządzania lukami w zabezpieczeniach można znaleźć na stronie: https://www.atlassian.com/trust/security/vulnerability-management.

6.08.

Podobnie jak w przypadku bezpieczeństwa pracowników, wiele potencjalnych problemów wynika z faktu, że infrastruktura IT jest kontrolowana przez podmiot zewnętrzny w tradycyjnym modelu outsourcingu, a skutki naruszenia zabezpieczeń fizycznych mogą wpływać na wielu klientów (wiele organizacji).

6.08. (a)

Jakich gwarancji udzielacie klientom w zakresie zabezpieczeń fizycznych samej lokalizacji? Proszę podać przykłady oraz wszelkie spełniane normy, np. sekcja 9 normy ISO 27001/2.

Zabezpieczenia fizyczne stosowane w naszych biurach wynikają z naszych zasad zapewniania bezpieczeństwa fizycznego i środowiskowego, które gwarantują wdrożenie w naszych środowiskach lokalnych i chmurowych solidnych zabezpieczeń fizycznych.

Współpracujące z nami centra danych muszą wykazać zgodność co najmniej z normą SOC-2. Te certyfikaty uwzględniają szereg środków kontroli, w tym ochrony i zabezpieczeń fizycznych oraz środowiskowych. Dostęp do centrów danych jest ograniczony 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.

6.08. (a) (i)

Kto oprócz upoważnionych pracowników IT ma samodzielny (fizyczny) dostęp do infrastruktury IT?

• Przykładowo personel sprzątający, menedżerowie, pracownicy ochrony fizycznej, wykonawcy, konsultanci, dostawcy itp.

Biura Atlassian podlegają wewnętrznym zasadom dotyczącym bezpieczeństwa fizycznego i środowiskowego, w tym monitorowaniu fizycznych punktów wejścia i wyjścia. Fragmenty wszystkich naszych wewnętrznych operacji technologicznych i zasad dotyczących bezpieczeństwa opublikowaliśmy na stronie: https://www.atlassian.com/trust/security/ismp-policies

W biurach Atlassian stosowane są środki kontroli dostępu, w tym czytniki identyfikatorów oraz monitoring wizyjny. Mamy również możliwość ograniczenia dostępu do określonych godzin lub dni, jeśli zajdzie taka potrzeba. Dzienniki dostępu do budynków biurowych są prowadzone przez dział zarządzania budynkiem i są dostępne do analizy dla działu odpowiedzialnego za środowisko pracy.

Nasze partnerskie centra danych mają wiele certyfikatów zgodności. Te certyfikaty dotyczą bezpieczeństwa fizycznego, 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. Informacje na temat zapewniania bezpieczeństwa fizycznego AWS można znaleźć pod adresem: http://aws.amazon.com/compliance

6.08. (a) (ii)

Jak często są sprawdzane prawa dostępu?

• Jak szybko można odwołać prawa dostępu?

Atlassian ocenia wydajność i skuteczność swojego systemu ISMS przy użyciu odpowiednich wskaźników. Wydajność systemu Atlassian Trust Management System (ATMS) oraz odpowiednich środków kontroli dostępu monitorujemy za pośrednictwem audytów wewnętrznych i zewnętrznych. Zespół ds. zgodności Atlassian zarządza zarówno naszym harmonogramem audytów wewnętrznych oraz wewnętrznych audytów gotowości, jak i harmonogramem audytów zewnętrznych (które są udokumentowane wewnętrznie na stronie Harmonogramy audytów). Audyty wewnętrzne koncentrują się na obszarach wysokiego ryzyka w Atlassian i są przeprowadzane regularnie zgodnie z wcześniej ustalonymi harmonogramami oraz harmonogramem audytu firmowego uzgodnionym między zespołem ds. ryzyka i zgodności a zespołem ds. audytu wewnętrznego. Obecnie nie publikujemy naszych wskaźników wewnętrznych. System ATMS jest oceniany corocznie przez niezależne strony trzecie, a także po ewentualnych istotnych zmianach. Firma Atlassian uzyskała certyfikaty SOC 2, ISO 27001 i ISO 27018 dla każdej ze swoich najważniejszych usług chmurowych. Atlassian monitoruje również każdy z filarów systemu ATMS w ramach okresowych przeglądów operacyjnych, w tym konkretne wskaźniki dla każdego z nich. Obejmuje to cotygodniowe przeglądy stanu zgodności systemu ATMS i inne spotkania, które są dokumentowane wewnętrznie na naszej stronie ATMS: przegląd dotyczący stanu zgodności, a także na stronie Notatki ze spotkań w systemie ATMS. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/compliance.

Mamy formalny program zarządzania bezpieczeństwem i corocznie przeglądamy nasz Program zarządzania bezpieczeństwem informacji (ISMP). Więcej informacji na temat Programu zarządzania bezpieczeństwem można znaleźć na stronie https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (iii)

Czy regularnie oceniacie zagrożenia dla bezpieczeństwa oraz analizujecie dostęp do obiektów?

• Jak często to robicie?

Atlassian ocenia wydajność i skuteczność swojego systemu ISMS przy użyciu odpowiednich wskaźników. Wydajność systemu Atlassian Trust Management System (ATMS) oraz odpowiednich środków kontroli dostępu monitorujemy za pośrednictwem audytów wewnętrznych i zewnętrznych. Zespół ds. zgodności Atlassian zarządza zarówno naszym harmonogramem audytów wewnętrznych oraz wewnętrznych audytów gotowości, jak i harmonogramem audytów zewnętrznych (które są udokumentowane wewnętrznie na stronie Harmonogramy audytów). Audyty wewnętrzne koncentrują się na obszarach wysokiego ryzyka w Atlassian i są przeprowadzane regularnie zgodnie z wcześniej ustalonymi harmonogramami oraz harmonogramem audytu firmowego uzgodnionym między zespołem ds. ryzyka i zgodności a zespołem ds. audytu wewnętrznego. Obecnie nie publikujemy naszych wskaźników wewnętrznych. System ATMS jest oceniany corocznie przez niezależne strony trzecie, a także po ewentualnych istotnych zmianach. Firma Atlassian uzyskała certyfikaty SOC 2, ISO 27001 i ISO 27018 dla każdej ze swoich najważniejszych usług chmurowych. Atlassian monitoruje również każdy z filarów systemu ATMS w ramach okresowych przeglądów operacyjnych, w tym konkretne wskaźniki dla każdego z nich. Obejmuje to cotygodniowe przeglądy stanu zgodności systemu ATMS i inne spotkania, które są dokumentowane wewnętrznie na naszej stronie ATMS: przegląd dotyczący stanu zgodności, a także na stronie Notatki ze spotkań w systemie ATMS. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/compliance.

Mamy formalny program zarządzania bezpieczeństwem i corocznie przeglądamy nasz Program zarządzania bezpieczeństwem informacji (ISMP). Więcej informacji na temat Programu zarządzania bezpieczeństwem można znaleźć na stronie https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (iv)

Czy przeprowadzacie regularne oceny ryzyka, obejmujące np. sąsiednie budynki?

Atlassian ocenia wydajność i skuteczność swojego systemu ISMS przy użyciu odpowiednich wskaźników. Wydajność systemu Atlassian Trust Management System (ATMS) oraz odpowiednich środków kontroli dostępu monitorujemy za pośrednictwem audytów wewnętrznych i zewnętrznych. Zespół ds. zgodności Atlassian zarządza zarówno naszym harmonogramem audytów wewnętrznych oraz wewnętrznych audytów gotowości, jak i harmonogramem audytów zewnętrznych (które są udokumentowane wewnętrznie na stronie Harmonogramy audytów). Audyty wewnętrzne koncentrują się na obszarach wysokiego ryzyka w Atlassian i są przeprowadzane regularnie zgodnie z wcześniej ustalonymi harmonogramami oraz harmonogramem audytu firmowego uzgodnionym między zespołem ds. ryzyka i zgodności a zespołem ds. audytu wewnętrznego. Obecnie nie publikujemy naszych wskaźników wewnętrznych. System ATMS jest oceniany corocznie przez niezależne strony trzecie, a także po ewentualnych istotnych zmianach. Firma Atlassian uzyskała certyfikaty SOC 2, ISO 27001 i ISO 27018 dla każdej ze swoich najważniejszych usług chmurowych. Atlassian monitoruje również każdy z filarów systemu ATMS w ramach okresowych przeglądów operacyjnych, w tym konkretne wskaźniki dla każdego z nich. Obejmuje to cotygodniowe przeglądy stanu zgodności systemu ATMS i inne spotkania, które są dokumentowane wewnętrznie na naszej stronie ATMS: przegląd dotyczący stanu zgodności, a także na stronie Notatki ze spotkań w systemie ATMS. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/compliance.

Mamy formalny program zarządzania bezpieczeństwem i corocznie przeglądamy nasz Program zarządzania bezpieczeństwem informacji (ISMP). Więcej informacji na temat Programu zarządzania bezpieczeństwem można znaleźć na stronie https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (v)

Czy kontrolujecie lub monitorujecie personel (w tym osoby trzecie), który uzyskuje dostęp do obszarów z ograniczonym dostępem?

Biura Atlassian podlegają wewnętrznym zasadom dotyczącym bezpieczeństwa fizycznego i środowiskowego, w tym monitorowaniu fizycznych punktów wejścia i wyjścia. Fragmenty wszystkich naszych wewnętrznych operacji technologicznych i zasad dotyczących bezpieczeństwa opublikowaliśmy na stronie: https://www.atlassian.com/trust/security/ismp-policies

W biurach Atlassian stosowane są środki kontroli dostępu, w tym czytniki identyfikatorów oraz monitoring wizyjny. Mamy również możliwość ograniczenia dostępu do określonych godzin lub dni, jeśli zajdzie taka potrzeba. Dzienniki dostępu do budynków biurowych są prowadzone przez dział zarządzania budynkiem i są dostępne do analizy dla działu odpowiedzialnego za środowisko pracy.

Nasze partnerskie centra danych mają wiele certyfikatów zgodności. Te certyfikaty dotyczą bezpieczeństwa fizycznego, 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. Informacje na temat zapewniania bezpieczeństwa fizycznego AWS można znaleźć pod adresem: http://aws.amazon.com/compliance

6.08. (a) (vi)

Jakie zasady lub procedury są stosowane w zakresie załadunku, rozładunku oraz instalacji sprzętu?

W obiektach biurowych Atlassian doki załadunkowe są odizolowane od obszarów roboczych oraz są przez cały czas monitorowane przez CCTV i personel budynku. Nasi partnerzy hostujący centra danych zarządzają bezpieczeństwem fizycznym, a my polegamy na ich certyfikatach zgodności, aby sprawdzić, czy kontrole są skuteczne.

6.08. (a) (vii)

Czy przed instalacją dostawy są sprawdzane pod kątem ryzyka?

W obiektach biurowych Atlassian doki załadunkowe są odizolowane od obszarów roboczych oraz są przez cały czas monitorowane przez CCTV i personel budynku. Nasi partnerzy hostujący centra danych zarządzają bezpieczeństwem fizycznym, a my polegamy na ich certyfikatach zgodności, aby sprawdzić, czy kontrole są skuteczne.

6.08. (a) (viii)

Czy w centrum danych istnieje aktualny fizyczny wykaz wszystkich zinwentaryzowanych pozycji?

Fragment naszej Polityki zarządzania zasobami jest dostępny na stronie https://www.atlassian.com/trust/security/ismp-policies. Firma Atlassian prowadzi inwentaryzację wszystkich zasobów produkcyjnych wraz z ich właścicielami. Wszystkie nasze systemy znajdują się w centrach danych opartych na AWS. Ze względu na charakter usługi te systemy AWS nie są monitorowane na poziomie sprzętowym.

Wszystkie mikrousługi są śledzone w niestandardowej bazie danych usług, która jest aktualizowana wraz z wdrożeniem dowolnej usługi. Zespół Atlassian ds. technologii w miejscu pracy (WPT) prowadzi wykaz zasobów wszystkich punktów końcowych, wykorzystując do śledzenia nasze własne oprogramowanie Jira Software.

Wszystkie mikrousługi są podzielone na poziomy istotności, które mają swój czas działania, dostępność oraz oczekiwania RTO i RPO. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/security/data-management.

6.08. (a) (ix)

Czy kable sieciowe biegną przez obszary dostępne publicznie?

• Czy używacie okablowania zbrojonego lub kanałów kablowych?

Biura Atlassian podlegają wewnętrznym zasadom dotyczącym bezpieczeństwa fizycznego i środowiskowego, w tym monitorowaniu fizycznych punktów wejścia i wyjścia. Fragmenty wszystkich naszych wewnętrznych operacji technologicznych i zasad dotyczących bezpieczeństwa opublikowaliśmy na stronie https://www.atlassian.com/trust/security/ismp-policies

W biurach Atlassian stosowane są środki kontroli dostępu, w tym czytniki identyfikatorów oraz monitoring wizyjny. Mamy również możliwość ograniczenia dostępu do określonych godzin lub dni, jeśli zajdzie taka potrzeba. Dzienniki dostępu do budynków biurowych są prowadzone przez dział zarządzania budynkiem i są dostępne do analizy dla działu odpowiedzialnego za środowisko pracy.

6.08. (a) (x)

Czy regularnie sprawdzacie pomieszczenia w poszukiwaniu nieautoryzowanego sprzętu?

Fragment naszej Polityki zarządzania zasobami jest dostępny na stronie https://www.atlassian.com/trust/security/ismp-policies. Firma Atlassian prowadzi inwentaryzację wszystkich zasobów produkcyjnych wraz z ich właścicielami. Wszystkie nasze systemy znajdują się w centrach danych opartych na AWS. Ze względu na charakter usługi te systemy AWS nie są monitorowane na poziomie sprzętowym.

Wszystkie mikrousługi są śledzone w niestandardowej bazie danych usług, która jest aktualizowana wraz z wdrożeniem dowolnej usługi. Zespół Atlassian ds. technologii w miejscu pracy (WPT) prowadzi wykaz zasobów wszystkich punktów końcowych, wykorzystując do śledzenia nasze własne oprogramowanie Jira Software.

6.08. (a) (xi)

Czy jakiś sprzęt jest zlokalizowany poza siedzibą firmy?

• Jak jest chroniony?

Fragment naszej Polityki zarządzania zasobami jest dostępny na stronie https://www.atlassian.com/trust/security/ismp-policies. Firma Atlassian prowadzi inwentaryzację wszystkich zasobów produkcyjnych wraz z ich właścicielami. Wszystkie nasze systemy znajdują się w centrach danych opartych na AWS. Ze względu na charakter usługi te systemy AWS nie są monitorowane na poziomie sprzętowym.

Wszystkie mikrousługi są śledzone w niestandardowej bazie danych usług, która jest aktualizowana wraz z wdrożeniem dowolnej usługi. Zespół Atlassian ds. technologii w miejscu pracy (WPT) prowadzi wykaz zasobów wszystkich punktów końcowych, wykorzystując do śledzenia nasze własne oprogramowanie Jira Software.

6.08. (a) (xii)

Czy personel firmy korzysta ze sprzętu przenośnego (np. laptopów, smartfonów), który może dać dostęp do centrum danych?

• Jak jest chroniony?

Nasze partnerskie centra danych mają wiele certyfikatów zgodności. Te certyfikaty dotyczą bezpieczeństwa fizycznego, 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. Informacje na temat zapewniania bezpieczeństwa fizycznego AWS można znaleźć na stronie http://aws.amazon.com/compliance/

Autoryzowani i przeszkoleni członkowie zespołów inżynierów Atlassian, którzy przeszli kontrolę przeszłości, uwierzytelniają się w sieci VPN przy użyciu unikatowych silnych haseł i uwierzytelniania dwuskładnikowego opartego na TOTP, a następnie uzyskują wyłącznie dostęp do środowiska produkcyjnego za pośrednictwem połączeń terminalowych SSH przy użyciu osobistych certyfikatów RSA chronionych hasłem. Na wszystkich serwerach produkcyjnych działa system IDS, który obejmuje monitorowanie w czasie rzeczywistym i powiadamianie o wszelkich zmianach w plikach systemu produkcyjnego lub konfiguracji oraz o anomaliach w zabezpieczeniach. W przypadku upoważnionych i przeszkolonych członków zespołu operacyjnego posiadających dostęp do systemu produkcyjnego wszystkie stacje robocze z systemem Windows lub OS X używane do uzyskiwania dostępu do środowiska produkcyjnego za pośrednictwem połączeń terminalowych SSH muszą posiadać aktualne i aktywne oprogramowanie antywirusowe. Dane klientów nie są replikowane na stacjach roboczych pracowników ani na urządzeniach mobilnych.

6.08. (a) (xiii)

Jakie środki są stosowane w celu kontrolowania kart dostępu?

Biura Atlassian podlegają wewnętrznym zasadom dotyczącym bezpieczeństwa fizycznego i środowiskowego, w tym monitorowaniu fizycznych punktów wejścia i wyjścia. Fragmenty wszystkich naszych wewnętrznych operacji technologicznych i zasad dotyczących bezpieczeństwa opublikowaliśmy na stronie https://www.atlassian.com/trust/security/ismp-policies

W biurach Atlassian stosowane są środki kontroli dostępu, w tym czytniki identyfikatorów oraz monitoring wizyjny. Mamy również możliwość ograniczenia dostępu do określonych godzin lub dni, jeśli zajdzie taka potrzeba. Dzienniki dostępu do budynków biurowych są prowadzone przez dział zarządzania budynkiem i są dostępne do analizy dla działu odpowiedzialnego za środowisko pracy.

6.08. (a) (xiv)

Jakie procesy lub procedury są stosowane w celu niszczenia starych nośników lub systemów, gdy jest to wymagane?

• Nadpisanie danych?
• Fizyczne niszczenie?

Proces ten obsługuje zespół ds. technologii w miejscu pracy. Sprzęt jest poddawany sanityzacji danych i odpowiednio rozmagnesowywany. Firma Atlassian nie zarządza żadnymi nośnikami fizycznymi, które obsługują jej produkty i usługi w chmurze.

6.08. (a) (xv)

Jakie procesy autoryzacji są stosowane do przemieszczania sprzętu z jednego miejsca do drugiego?

• Jak zidentyfikować pracowników (lub wykonawców), którzy są do tego upoważnieni?

Nasi partnerzy hostujący centra danych (AWS) zarządzają bezpieczeństwem fizycznym, a my polegamy na ich procedurze SOC 2, aby weryfikować, czy kontrole są skuteczne.

Produkty Atlassian Cloud nie przenoszą fizycznie danych klientów. Dyski twarde z danymi klientów są niszczone lub sanityzowane przed opuszczeniem naszych zabezpieczonych centrów danych AWS. W przypadku systemów hostowanych w AWS dane mogą być przenoszone między regionami w scenariuszu redundancji, ale pozostaną w AWS. Więcej informacji na temat poszczególnych regionów można znaleźć na stronie https://www.atlassian.com/trust/reliability/infrastructure.

6.08. (a) (xvi)

Jak często przeprowadzane są audyty sprzętu w celu monitorowania nieautoryzowanego usuwania sprzętu?

Nasi partnerzy hostujący centra danych (AWS) zarządzają bezpieczeństwem fizycznym, a my polegamy na ich procedurze SOC 2, aby weryfikować, czy kontrole są skuteczne.

Produkty Atlassian Cloud nie przenoszą fizycznie danych klientów. Dyski twarde z danymi klientów są niszczone lub sanityzowane przed opuszczeniem naszych zabezpieczonych centrów danych AWS. W przypadku systemów hostowanych w AWS dane mogą być przenoszone między regionami w scenariuszu redundancji, ale pozostaną w AWS. Więcej informacji na temat poszczególnych regionów można znaleźć na stronie https://www.atlassian.com/trust/reliability/infrastructure.

6.08. (a) (xvii)

Jak często przeprowadzane są kontrole w celu zapewnienia zgodności środowiska z odpowiednimi wymogami prawnymi i regulacyjnymi?

Dział prawny i zespoły ds. zgodności Atlassian monitorują nasze obowiązki regulacyjne. Informacje na temat naszego programu prawnego znajdują się na stronie https://www.atlassian.com/legal/. Więcej informacji na temat naszego programu zgodności można znaleźć tutaj: https://www.atlassian.com/trust/compliance.

6.09. (a)

Jakie wprowadziliście procedury lub zasady gwarantujące, że problemy środowiskowe nie powodują przerw w świadczeniu usług?

Biura Atlassian podlegają wewnętrznym zasadom dotyczącym bezpieczeństwa fizycznego i środowiskowego, w tym monitorowaniu fizycznych punktów wejścia i wyjścia. Nasze partnerskie centra danych mają wiele certyfikatów zgodności. Te certyfikaty dotyczą bezpieczeństwa fizycznego, 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. Informacje na temat zapewniania bezpieczeństwa fizycznego AWS można znaleźć na stronie http://aws.amazon.com/compliance/

Obowiązują zasady „Zachowanie ciągłości działania i odzyskiwanie awaryjne” oraz „Plan odzyskiwania awaryjnego i ciągłości działalności biznesowej”. Są one co roku poddawane przeglądowi przez komitet sterujący ds. ciągłości działalności biznesowej / odzyskiwania awaryjnego. Wszyscy właściciele systemów, procesów lub usług o znaczeniu krytycznym zapewniają odpowiednią ciągłość działania i/lub odzyskiwanie awaryjne (BCDR) na poziomie odpowiadającym tolerancji na zakłócenia w razie awarii. Plany BCDR są testowane co kwartał, a wszelkie zidentyfikowane problemy są rozwiązywane. Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management oraz https://www.atlassian.com/trust/security/data-management.

6.09. (b)

Jakich metod używacie, aby zapobiegać szkodom spowodowanym przez pożary, powodzie, trzęsienia ziemi itp.?

• Jakie dodatkowe środki bezpieczeństwa są wprowadzone w celu zabezpieczenia dostępu fizycznego w razie wystąpienia katastrofy?
• Zarówno w lokalizacjach podstawowych, jak i drugorzędnych?

Atlassian polega na swoich partnerach zajmujących się hostingiem danych w celu weryfikacji bezpieczeństwa centrów danych i kontroli środowiskowych. W przypadku AWS patrz https://aws.amazon.com/compliance/programs.

6.09. (c)

Czy monitorujecie temperaturę i wilgotność w centrum danych?

• Czy sprawdzacie lub monitorujecie sprzęt klimatyzacyjny?

Atlassian polega na swoich partnerach zajmujących się hostingiem danych w celu weryfikacji bezpieczeństwa centrów danych i kontroli środowiskowych. W przypadku AWS patrz https://aws.amazon.com/compliance/programs.

6.09. (d)

Czy chronicie swoje budynki przed uderzeniem pioruna?

• W tym linie elektryczne i komunikacyjne?

Atlassian polega na swoich partnerach zajmujących się hostingiem danych w celu weryfikacji bezpieczeństwa centrów danych i kontroli środowiskowych. W przypadku AWS patrz https://aws.amazon.com/compliance/programs.

6.09. (e)

Czy posiadacie zapasowe agregaty prądotwórcze na wypadek awarii zasilania?

• Jak długo mogą pracować?
• Czy zapasy paliwa są wystarczające?
• Czy posiadacie agregaty z przełączaniem awaryjnym?
• Jak często sprawdzacie sprzęt UPS?
• Jak często sprawdzacie swoje agregaty prądotwórcze?
• Czy macie wielu dostawców energii?

Atlassian polega na swoich partnerach zajmujących się hostingiem danych w celu weryfikacji bezpieczeństwa centrów danych i kontroli środowiskowych. W przypadku AWS patrz https://aws.amazon.com/compliance/programs.

6.09. (f)

Czy wszystkie media (prąd, woda itp.) są w stanie wspierać Wasze środowisko?

• Jak często jest to ponownie oceniane i testowane?

Atlassian polega na swoich partnerach zajmujących się hostingiem danych w celu weryfikacji bezpieczeństwa centrów danych i kontroli środowiskowych. W przypadku AWS patrz https://aws.amazon.com/compliance/programs.

6.09. (g)

Czy urządzenia klimatyzacyjne są w stanie wspierać Wasze środowisko?

• Jak często jest to testowane?

Atlassian polega na swoich partnerach zajmujących się hostingiem danych w celu weryfikacji bezpieczeństwa centrów danych i kontroli środowiskowych. W przypadku AWS patrz https://aws.amazon.com/compliance/programs.

6.09. (h)

Czy przestrzegacie zalecanych przez producentów harmonogramów konserwacji?

Atlassian polega na swoich partnerach zajmujących się hostingiem danych w celu weryfikacji bezpieczeństwa centrów danych i kontroli środowiskowych. W przypadku AWS patrz https://aws.amazon.com/compliance/programs.

6.09. (i)

Czy wpuszczasz do obiektów firmy tylko upoważnionych serwisantów?

• Jak sprawdzasz ich tożsamość?

Sposobem na ochronę fizycznego dostępu do pomieszczeń biurowych jest na przykład wykorzystanie identyfikatorów elektronicznych, obowiązkowe meldowanie się gości w recepcji w godzinach pracy czy monitorowane przez CCTV we wszystkich punktach wejścia do budynku i wyjścia z niego. Doki załadunkowe są przez cały czas monitorowane przez CCTV i personel budynku. Nasi partnerzy hostujący centra danych zarządzają bezpieczeństwem fizycznym, a my polegamy na ich certyfikatach zgodności w zakresie sprawdzania skuteczności kontroli.

6.09. (j)

Czy kiedy sprzęt jest wysyłany do naprawy, najpierw są z niego usuwane dane?

• Jak się to odbywa?

Proces ten obsługuje zespół ds. technologii w miejscu pracy. Sprzęt jest poddawany sanityzacji danych i odpowiednio rozmagnesowywany. Firma Atlassian nie zarządza żadnymi nośnikami fizycznymi, które obsługują jej produkty i usługi w chmurze.

6.10.

Klienci i potencjalni klienci usług dostawców chmurowych powinni mieć na uwadze swoje krajowe i międzynarodowe obowiązki w zakresie zgodności z ramami regulacyjnymi i dopilnować, aby wszelkie takie obowiązki były odpowiednio przestrzegane.

Najważniejsze pytania prawne, które klient powinien zadać dostawcy usług w chmurze, są następujące:

6.10. (a)

W jakim kraju działa dostawca usług w chmurze?

Atlassian ma 12 biur w 8 krajach, w tym w Sydney, Amsterdamie, Ankarze, Bostonie, Bengaluru, San Francisco, Mountain View, Austin w Teksasie, Nowym Jorku, Manili, Gdańsku i Japonii. Więcej informacji można znaleźć na stronie: https://www.atlassian.com/company/contact.

6.10. (b)

Czy infrastruktura dostawcy usług w chmurze jest zlokalizowana w tym samym kraju, czy w innych krajach?

W przypadku Atlassian Cloud jesteśmy obecnie hostowani w nadmiarowych strefach dostępności AWS. Więcej informacji na temat poszczególnych regionów można znaleźć pod adresem: https://www.atlassian.com/trust/reliability/infrastructure.

6.10. (c)

Czy dostawca usług w chmurze będzie korzystał z usług innych firm, których infrastruktura znajduje się poza jego lokalizacją?

Produkty oraz dane Atlassian Cloud są hostowane przez wiodącego w branży dostawcę usług w chmurze — Amazon Web Services (AWS). Nasze produkty działają w środowisku PaaS (Platform as a Service) podzielonym na dwa główne zbiory infrastruktury, które określamy jako Micros i inny niż Micros. Produkty Jira, Confluence, Statuspage, Access i Bitbucket działają na platformie Micros, a Opsgenie i Trello na innej niż Micros.

6.10. (d)

Gdzie będą fizycznie znajdować się dane?

Atlassian korzysta z usług Amazon Web Services (AWS) w regionach US-East, US-West, Irlandii, Frankfurtu, Singapuru i Sydney (Confluence i Jira).

Szczegółowe informacje o konkretnych produktach:

• Trello: dostępne w AWS US-East (Ohio).
• Jira Align: o informacje na temat fizycznej lokalizacji danych klienta można poprosić za pośrednictwem zgłoszenia pomocy technicznej. Zobacz: https://support.atlassian.com/jira-align/.
• Statuspage: dostępne w regionach AWS US-West (Oregon, Kalifornia) US-East (Ohio).
• Opsgenie: ma konta AWS zarówno w USA, jak i w Europie. Podczas rejestracji klient musi wyrazić zgodę na region AWS w USA (Oregon, Kalifornia) lub UE (Frankfurt).
• Halp: hostowany w AWS w regionach US-East-2 i US-West-2.
• Bitbucket: repozytoria i podstawowe funkcje aplikacji są hostowane w AWS w regionach US-East i US-West.


Więcej informacji na temat miejsce przechowywania danych można znaleźć na stronie: https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/.

6.10. (e)

Czy jurysdykcja dotycząca warunków umowy i danych będzie podzielona?

Domyślnym prawem właściwym w przypadku umów z klientem Atlassian jest prawo stanu Kalifornia. Aby uzyskać więcej informacji, skontaktuj się z naszym zespołem sprzedaży produktów Enterprise.

6.10. (f)

Czy którakolwiek z usług dostawcy w chmurze zostanie zlecona podwykonawcom?

Atlassian współpracuje z zewnętrznymi podwykonawcami przy dostarczaniu witryn internetowych, tworzeniu aplikacji, hostingu, konserwacji, tworzeniu kopii zapasowych, przechowywaniu danych, infrastrukturze wirtualnej, przetwarzaniu płatności, analizie i innych usługach. Ci dostawcy usług mogą mieć dostęp do identyfikowalnych danych osobowych lub przetwarzać je w celu świadczenia tych usług dla nas.

Atlassian informuje swoich klientów o korzystaniu z usług podwykonawców, którzy mogą przetwarzać ich dane osobowe, poprzez powiadomienie przed rozpoczęciem przetwarzania. Zewnętrzna lista podwykonawców, z którymi współpracuje Atlassian, znajduje się na stronie podwykonawców przetwarzania Atlassian pod adresem: https://www.atlassian.com/legal/sub-processors. Na tej stronie odwiedzający są proszeni o subskrypcję kanału RSS, aby otrzymywać powiadomienia o dodaniu nowych podwykonawców przetwarzania Atlassian.

6.10. (g)

Czy którakolwiek z usług dostawcy w chmurze zostanie zlecona w ramach outsourcingu?

Jeśli Atlassian angażuje jakichkolwiek dostawców zewnętrznych, staramy się, aby takie przedsięwzięcia w żaden sposób nie narażały na ryzyko naszych klientów ani ich danych. Zespoły prawne i zakupowe Atlassian sprawdzają umowy, umowy SLA i wewnętrzne zasady dostawców, aby określić, czy dostawca spełnia wymagania dotyczące bezpieczeństwa, dostępności i poufności. Więcej informacji można znaleźć na stronie: https://www.atlassian.com/trust/security/security-practices#supplier-risk-management.

6.10. (h)

W jaki sposób dane dostarczone przez klienta i jego klientów są gromadzone, przetwarzane i przekazywane?

Atlassian przetwarza informacje w sposób zgodny z celami, dla których są gromadzone lub do których upoważniła nas dana osoba, w szczególności zgodnie z zewnętrzną polityką prywatności Atlassian.

Prywatność użytkowników jest bardzo ważna dla Atlassian, podobnie jak przejrzystość sposobu zbierania, wykorzystywania i udostępniania informacji o użytkownikach. Więcej informacji można znaleźć w sekcji „Ochrona prywatności w Atlassian” w Atlassian Trust Center na stronie https://www.atlassian.com/trust/privacy oraz w naszej polityce prywatności na stronie https://www.atlassian.com/legal/privacy-policy.

6.10. (i)

Co się dzieje z danymi wysyłanymi do dostawcy chmury po rozwiązaniu umowy?

Firma Atlassian przestrzega standardów dotyczących przechowywania i niszczenia danych, które określają, jak długo musimy zatrzymywać różnego rodzaju dane. Dane są klasyfikowane zgodnie z zasadami firmy Atlassian dotyczącymi bezpieczeństwa danych i cyklu życia informacji, a na tej podstawie wdrażane są środki kontroli. W przypadku danych klienta w momencie rozwiązania umowy z firmą Atlassian dane należące do zespołu klienta zostaną usunięte z aktywnej produkcyjnej bazy danych, w wszystkie pliki załączników przekazane bezpośrednio do firmy Atlassian zostaną usunięte w ciągu 14 dni. Dane zespołu zostaną zachowane w zaszyfrowanych kopiach zapasowych przez 90 dni, a następnie zniszczone zgodnie z zasadami przechowywania danych firmy Atlassian. Jeśli w ciągu 90 dni od zażądania usunięcia danych konieczne okaże się przywrócenie bazy danych, zespół odpowiedzialny za eksploatację systemów ponownie usunie dane możliwie jak najszybciej po pełnym przywróceniu aktywnego systemu produkcyjnego. Więcej informacji można znaleźć pod adresem: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/