| Zasada 1: Ochrona danych podczas przesyłania |
| 1.1 Szyfrowanie | Firma Atlassian stosuje szyfrowanie w wewnętrznej sieci bezprzewodowej, z uwzględnieniem modyfikacji domyślnych ustawień dostawcy. Zespół Atlassian ds. technologii w miejscu pracy chroni nasze sieci bezprzewodowe przez zastosowanie uwierzytelniania WPA2-AES oraz szyfrowania PEAP-EAP-MSCHAPv2. Uwierzytelnianie w naszej sieci bezprzewodowej odbywa się przy użyciu standardu 802.1x z wykorzystaniem naszego wewnętrznego magazynu tożsamości. Regularnie przeprowadzamy skanowanie pod kątem nieautoryzowanych punktów dostępu bezprzewodowego i prowadzimy rejestr wykrytych punktów dostępu tego typu.
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. | Nasze zasady dotyczące bezpieczeństwa i ochrony prywatności danych
Szyfrowanie danych | Atlassian Trust Center
Szyfrowanie danych | Praktyki operacyjne i architektura Atlassian Cloud |
| 1.2 Ochrona sieci | Program Policy Management Program (PMP) firmy Atlassian obejmuje Zasady bezpieczeństwa komunikacji, które określają obowiązki związane z zarządzaniem siecią.
Do obsługi dostępu do sieci firma Atlassian wykorzystuje scentralizowany katalog z włączoną obsługą protokołu LDAP, wdrażając kontrolę dostępu opartą na rolach i wykorzystującą zdefiniowane profile. Użytkownicy otrzymują odpowiednie prawa dostępu w oparciu o te profile, sterowane za pomocą przepływu pracy z naszego systemu zarządzania HR. Reguły dostępu do wewnętrznej sieci produkcyjnej są stosowane przy użyciu specjalnie do tego wyznaczonych grup zabezpieczeń w środowiskach VPC AWS.
Zespół Atlassian ds. technologii w miejscu pracy chroni sieci bezprzewodowe przez zastosowanie uwierzytelniania WPA2-AES oraz szyfrowania PEAP-EAP-MSCHAPv2. Uwierzytelnianie w naszej sieci bezprzewodowej odbywa się przy użyciu standardu 802.1x z wykorzystaniem naszego wewnętrznego magazynu tożsamości.
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. Wdrożenia TLS firmy Atlassian wymuszają stosowanie silnych szyfrów. | Nasze zasady dotyczące bezpieczeństwa i ochrony prywatności danych
Włączanie zabezpieczeń do naszej architektury sieciowej | Atlassian Trust Center |
| 1.3 Uwierzytelnianie | 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.
W przypadku 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 Atlassian Cloud za pośrednictwem Atlassian Access, patrz: https://www.atlassian.com/enterprise/cloud/access. | Nasze zasady dotyczące bezpieczeństwa i ochrony prywatności danych
Zabezpieczanie dostępu do naszych sieci w myśl zasady Zero Trust | Atlassian Trust Center
Uwierzytelnianie i autoryzacja usług | Praktyki operacyjne i architektura Atlassian Cloud |
| Zasada 2: Ochrona zasobów i odporność |
| 2.1 Lokalizacja fizyczna i jurysdykcja prawna | Lokalizacja fizyczna
Obecnie Atlassian utrzymuje centra danych i hostuje dane w Stanach Zjednoczonych, Niemczech, Irlandii, Singapurze i Australii. Hostowanie zawartości klientów w wielu regionach na całym świecie pozwala nam dostarczać wszystkim klientom bezpieczne, szybkie i niezawodne usługi.
Wszystkie systemy produkcyjne Atlassian Cloud znajdują się w regionach AWS obejmujących US-East (wschodnia część USA), US-West (zachodnia część USA), Irlandię, Frankfurt, Singapur i Sydney.
Podczas rejestracji platforma firmy Atlassian optymalizuje miejsce przechowywania danych klienta w oparciu o lokalizację dostępu, aby zapewnić większą niezawodność i zmniejszyć opóźnienia.
Obecnie jurysdykcja danych jest dostępna w ramach naszych planów Standard, Premium i Enterprise chmurowych wersji rozwiązań Jira Software, Confluence i Jira Service Management. Można także zdecydować, czy dane związane z konkretnym produktem będą hostowane w Australii, Europie czy Stanach Zjednoczonych. Dowiedz się więcej o środkach kontroli jurysdykcji danych.
Można również sprawdzać nasz plan rozwoju wersji Cloud, w którym znajdują się najnowsze aktualności, w tym informacje na temat jurysdykcji danych w dodatkowych lokalizacjach, jurysdykcji danych dla poszczególnych aplikacji i wiele więcej. | Lokalizacja fizyczna
Zapewnianie bezpieczeństwa danych | Atlassian Trust Center
Infrastruktura hostingu Atlassian Cloud | Praktyki operacyjne i architektura Atlassian Cloud |
| Wykorzystywanie Twoich danych
Patrz Umowa z klientem firmy Atlassian, Polityka prywatności i Aneks dotyczący przetwarzania danych. | Wykorzystywanie Twoich danych
Umowa z klientem firmy Atlassian | Atlassian
Polityka prywatności Atlassian | Atlassian
Aneks dotyczący przetwarzania danych | Atlassian |
| Dodatkowe uwagi
Zapoznaj się ze zobowiązaniem Atlassian w zakresie RODO oraz innych aktów prawnych dotyczących ochrony danych. | Dodatkowe uwagi
Zobowiązanie Atlassian w zakresie RODO | Atlassian |
| 2.2 Bezpieczeństwo centrów danych | To zagadnienie zostało omówione w Aneksie dotyczącym przetwarzania danych firmy Atlassian, w którym firma Atlassian zobowiązuje się do ochrony Twoich danych, w tym do zapewniania bezpieczeństwa centrów danych, sieci oraz samych danych.
Firma Atlassian przewiduje fizyczne zagrożenia dla swoich centrów danych i wdraża środki zaradcze, aby zapobiec skutkom takich zagrożeń lub ograniczyć ich wpływ.
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.
AWS ma wiele certyfikatów potwierdzających ochronę ich centrów danych. Informacje na temat zapewniania bezpieczeństwa fizycznego AWS można znaleźć na stronie http://aws.amazon.com/compliance/ | Patrz
https://www.atlassian.com/trust/security/securitypractices#physical-security |
| 2.3 Szyfrowanie danych | Firma Atlassian stosuje szyfrowanie w wewnętrznej sieci bezprzewodowej, z uwzględnieniem modyfikacji domyślnych ustawień dostawcy. Zespół Atlassian ds. technologii w miejscu pracy chroni nasze sieci bezprzewodowe przez zastosowanie uwierzytelniania WPA2-AES oraz szyfrowania PEAP-EAP-MSCHAPv2. Uwierzytelnianie w naszej sieci bezprzewodowej odbywa się przy użyciu standardu 802.1x z wykorzystaniem naszego wewnętrznego magazynu tożsamości. Regularnie przeprowadzamy skanowanie pod kątem nieautoryzowanych punktów dostępu bezprzewodowego i prowadzimy rejestr wykrytych punktów dostępu tego typu.
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źć pod adresem: https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management. | Nasze zasady dotyczące bezpieczeństwa i ochrony prywatności danych
Szyfrowanie danych | Atlassian Trust Center
Szyfrowanie danych | Praktyki operacyjne i architektura Atlassian Cloud |
| 2.4 Czyszczenie danych i utylizacja sprzętu | 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.
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źć pod adresem: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/ | Przechowywanie i usuwanie danych | Atlassian Trust Center
Śledzenie pamięci masowej i przenoszenie danych między produktami | Wsparcie Atlassian |
| 2.5 Odporność i dostępność fizyczna | 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. Te zasady obejmują takie dziedziny, jak bezpieczne obszary pracy, zabezpieczenia naszego sprzętu informatycznego, niezależnie od jego lokalizacji, ograniczenie dostępu do naszych budynków i biur do odpowiednich osób, a także monitorowanie fizycznych punktów wejścia i wyjścia. Wśród naszych praktyk zapewniania bezpieczeństwa fizycznego można wskazać obecność pracowników recepcji w godzinach pracy, wymóg rejestrowania gości oraz dostęp do obszarów niepublicznych za pomocą identyfikatorów. Współpracujemy również z kierownictwem naszego budynku biurowego w celu kontroli dostępu po godzinach i monitoringu wizyjnego wejść i wyjść, zarówno głównych, jak i zaopatrzeniowych.
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.
Oprócz wspomnianych powyżej środków, korzystając z własnego produktu Statuspage, udostępniamy naszym klientom w czasie rzeczywistym informacje o stanie dostępności naszych usług. W razie jakichkolwiek problemów z dowolnym z naszych produktów klienci dowiedzą się o tym, gdy tylko do nas samych dotrze taka informacja. | Bezpieczeństwo fizyczne | Atlassian Trust Center |
| Zasada 3: Separacja klientów |
| | Choć klienci używający produktów Atlassian korzystają ze wspólnej chmurowej infrastruktury informatycznej, stosujemy środki zapewniające logiczną separację klientów, tak aby działania jednego klienta nie wpływały na dane ani usługi innych klientów.
Podejście Atlassian do osiągnięcia takiego stanu zależy od rodzaju naszej aplikacji. W przypadku Jira i Confluence Cloud do logicznego odizolowania naszych klientów wykorzystujemy koncepcję nazywaną „kontekstem dzierżawcy”. Implementujemy ją na poziomie kodu aplikacji i zarządzamy przy użyciu opracowanej przez nas usługi o nazwie „Tenant Context Service” (TCS). Założenia tej koncepcji są następujące:
- Podczas magazynowania dane każdego klienta są logicznie oddzielone od innych dzierżawców.
- Wszelkie wnioski przetwarzane przez Jira lub Confluence mają widok „właściwy dla dzierżawcy”, co sprawia, że nie ma on wpływu na innych dzierżawców.
Ogólnie rzecz biorąc działanie usługi TCS opiera się na przechowywaniu „kontekstu” poszczególnych dzierżawców klienta. Kontekst każdego dzierżawcy jest powiązany z unikatowym identyfikatorem przechowywanym centralnie przez usługę TCS i obejmuje szereg metadanych skojarzonych z dzierżawcą (takich jak bazy danych, w których znajduje się dzierżawca; licencje posiadane przez dzierżawcę; funkcje, do których ma on dostęp oraz szereg innych informacji na temat konfiguracji). Gdy klient uzyskuje dostęp do Jira lub Confluence Cloud, usługa TCS używa identyfikatora dzierżawcy, aby zebrać te metadane, które następnie są łączone z dowolnymi operacjami podejmowanymi przez dzierżawcę w aplikacji w trakcie całej sesji.
Kontekst dostarczany przez usługę TCS pełni funkcję „soczewki”, przez którą przepuszczane są wszelkie interakcje z danymi klienta. Ta soczewka jest zawsze przypisana do jednego konkretnego dzierżawcy. Dzięki temu jeden dzierżawca klienta nie ma dostępu do danych innego dzierżawcy ani nie jest w stanie wpłynąć na usługę innego dzierżawcy podejmowanymi przez siebie działaniami.
Więcej informacji na temat naszej architektury chmury można znaleźć w zasobach wsparcia dotyczących chmury. | Praktyki operacyjne i architektura Atlassian Cloud | Atlassian Trust Center |
| Zasada 4: Ramy zarządzania |
| | Atlassian zdaje sobie sprawę, że podmioty regulowane muszą w ramach własnej oceny ryzyka dokonać weryfikacji naszych wewnętrznych środków kontroli, systemów oraz zabezpieczeń i środków ochrony prywatności powiązanych z usługami. Każdego roku firma Atlassian jest poddawana kilku niezależnym audytom zewnętrznym w celu zweryfikowania naszych działań operacyjnych i wewnętrznych środków kontroli.
Aby przejrzeć nasz aktualny program zapewniania zgodności z przepisami, przejdź do naszego Centrum zasobów na temat zgodności z przepisami, gdzie znajdziesz wszystkie weryfikacje i certyfikaty dotyczące naszych produktów w formie gotowej do pobrania.
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, w zależności od profilu ryzyka, funkcjonalne oceny ryzyka.
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. | Nasze zasady bezpieczeństwa i polityki prywatności
Zarządzanie zgodnością i ryzykiem | Atlassian Trust Center
Atlassian Trust Management System (ATMS) | Atlassian Trust Center
Aneks dotyczący przetwarzania danych | Atlassian Trust Center |
| Zasada 5: Bezpieczeństwo operacyjne |
| 5.1 Zarządzanie lukami w zabezpieczeniach | Atlassian nieustannie pracuje nad zmniejszeniem istotności i częstotliwości występowania luk w zabezpieczeniach swoich produktów, usług i infrastruktury. Dba także o jak najszybsze usuwanie zidentyfikowanych luk. W tym celu wdrożyliśmy wielopłaszczyznowe i stale rozwijane podejście do zarządzania lukami w zabezpieczeniach, które obejmuje zarówno zautomatyzowane, jak i ręczne procesy identyfikowania, śledzenia i usuwania luk w naszych aplikacjach i infrastrukturze.
Wszystkie nasze produkty i oferowane usługi są objęte rozbudowanym procesem usuwania błędów (w którym wykorzystujemy nasz własny produkt Jira do rejestrowania zgłoszeń i ułatwiania zarządzania rozwiązywaniem wniosków). U jego podstaw leżą liczne zasady dotyczące naprawiania błędów zabezpieczeń, usługi doradcze oraz poziomy SLO, których przestrzegamy. Przyjmujemy zgłoszenia błędów za pośrednictwem naszego kanału wsparcia, programu wykrywania błędów oraz pod adresem security@atlassian.com. Więcej informacji można znaleźć w witrynie Trust Center (https://www.atlassian.com/trust) oraz na stronie Usuwanie błędów zabezpieczeń — docelowe poziomy świadczenia usług (SLO) (https://www.atlassian.com/trust/security/bug-fix-policy).
Zespół ds. bezpieczeństwa Atlassian wykorzystuje wiele metod wykrywania luk w zabezpieczeniach, zarówno w infrastrukturze wewnętrznej, jak i zewnętrznej. 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 zidentyfikowanych 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.
Więcej informacji można znaleźć w artykule na temat podejścia Atlassian do zarządzania lukami w zabezpieczeniach.
Więcej informacji na temat naszego podejścia do testowania zabezpieczeń można znaleźć również w witrynie Trust Center: Podejście do zewnętrznych testów zabezpieczeń | Atlassian. | Zarządzanie lukami w zabezpieczeniach | Atlassian Trust Center
Zasady usuwania błędów zabezpieczeń | Atlassian Trust Center
Podejście do zewnętrznych testów zabezpieczeń | Atlassian Trust Center
Podejście do zarządzania lukami w zabezpieczeniach | Atlassian Trust Center |
| 5.2 Monitorowanie ochronne | Mając na uwadze potrzebę rozwijania naszego podejścia do zarządzania incydentami w kontekście coraz bardziej złożonych zagrożeń, wprowadziliśmy „program detekcji naruszeń zabezpieczeń”. Detekcje oznaczają wyszukiwania, które są uruchamiane proaktywnie zgodnie z harmonogramem na platformie zarządzania incydentami i zdarzeniami zabezpieczeń Atlassian w celu wykrycia złośliwej aktywności ukierunkowanej na firmę Atlassian lub jej klientów.
Nasz wykrywania i reagowania regularnie tworzy nowe detekcje, dostosowuje i doskonali istniejące oraz automatyzuje reakcje. Te czynności mają charakter wielowymiarowy, obejmują różne produkty, rodzaje ataków i źródła dzienników, aby zasięg naszych detekcji był możliwie jak najbardziej skuteczny i kompleksowy.
Program ma na celu nie tylko przygotować nas na zagrożenia, w obliczu których stajemy już dziś, ale także w dostatecznym stopniu przewidzieć zagrożenia, jakie mogą pojawić się w przyszłości, i przygotować nas na ich nadejście. Nasz zespół ds.wykrywania i reagowania opracował również narzędzie do standaryzacji tworzonych przez nas detekcji, aby zapewnić wysoki poziom spójności i jakości. Sądzimy, że jest to pierwsze tego typu rozwiązanie w branży.
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ń. Dzienniki kluczowych systemów są przekazywane dalej 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 lokacji (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źć pod adresem: https://www.atlassian.com/trust/security/detections-program. | Program detekcji Atlassian | Atlassian Trust Center
Korzystanie z dzienników | Atlassian Trust Center
Aneks dotyczący przetwarzania danych | Atlassian Trust Center |
| 5.3 Zarządzanie incydentami | Firma Atlassian stosuje kompleksowe podejście incydentów dotyczących bezpieczeństwa. Pod pojęciem incydentu dotyczącego bezpieczeństwa rozumiemy dowolny incydent wywierający negatywny wpływ na poufność, integralność lub dostępność danych klientów, danych Atlassian lub usług Atlassian.
Mamy wyraźnie zdefiniowane wewnętrzne zasady ramowe, które zawierają udokumentowane porady strategiczne dotyczące różnego rodzaju incydentów. Te zasady obejmują kroki, jakie musimy podejmować na każdym etapie reagowania na incydenty, aby zapewnić spójność, powtarzalność i efektywność naszych procesów. Można wśród nich wymienić wykrywanie i analizę, kategoryzację, powstrzymywanie eskalacji oraz eliminowanie incydentów, a także przywracanie pracy po ich wystąpieniu. Uzyskanie takiej spójności ułatwia zastosowanie naszych własnych produktów, w tym Confluence, Jira i Bitbucket, w ramach naszych procesów reagowania na incydenty:
- Rozwiązanie Confluence służy do tworzenia, dokumentowania i aktualizowania naszych procesów reagowania w centralnej lokalizacji.
- System Jira jest używany do tworzenia zgłoszeń w celu śledzenia postępów procesu reagowania na incydenty związane z bezpieczeństwem (potencjalne i rzeczywiste) od początku do końca.
- Aplikację Bitbucket wykorzystujemy w sytuacjach, gdy tworzymy rozwiązania na bazie kodu. Służą one do reagowania na konkretne skrajne problemy, jakie mają miejsce w przypadku pewnych rodzajów incydentów.
Wprowadziliśmy kompleksowe i scentralizowane dzienniki oraz monitorowanie naszych produktów i infrastruktury, aby umożliwić szybkie wykrywanie potencjalnych incydentów. Cały proces jest wspierany przez zespół wysoce wykwalifikowanych menedżerów ds. incydentów pełniących dyżury domowe, którzy posiadają bogate doświadczenie w koordynowaniu skutecznych reakcji. Mamy również dostęp do szeregu ekspertów zewnętrznych, którzy pomagają nam w badaniu incydentów i możliwie jak najbardziej efektywnym reagowaniu.
Dysponujemy procesami powiadamiania naszych klientów o wystąpieniu potwierdzonych incydentów z udziałem ich danych. Stosujemy także wydajną procedurę przeglądów po incydentach, która pozwala nam wyciągać wnioski z zaistniałych incydentów i doskonalić nasze praktyki w celu utrudnienia autorom złośliwych ataków działania w przyszłości. Więcej informacji można znaleźć w odrębnym artykule pt. Nasze podejście do zarządzania incydentami związanymi z bezpieczeństwem, który jest dostępny w Atlassian Trust Center. | Zarządzanie incydentami | Atlassian Trust Center
Aneks dotyczący przetwarzania danych | Atlassian Trust Center |
| 5.4 Zarządzanie konfiguracją i zmianami | Nasz proces zarządzania zmianami różni się nieco od tradycyjnego. Tradycyjne procesy zarządzania zmianami opierają się na hierarchii kontroli zmian przypominającej piramidę. Oznacza to, że gdy ktoś chce wprowadzić zmianę, musi przedstawić ją radzie, która ostatecznie ją zatwierdzi lub odrzuci.
Wdrożyliśmy podejście w stylu open source, które nazywamy „Peer Review, Green Build” (PRGB), czyli recenzja przez współpracownika i kompilacja gotowa do wdrożenia. W przeciwieństwie do tradycyjnego procesu zarządzania zmianami, podejście PRGB zakłada, że każda zmiana — czy to zmiana kodu, czy infrastruktury — jest sprawdzana przez co najmniej jednego współpracownika w celu wykrycia wszelkich problemów, jakie mogłaby potencjalnie spowodować. W zależności od stopnia krytyczności zmiany lub systemów, na które ma ona wpływ, zwiększamy liczbę recenzentów. Ufamy, że nasi inżynierowie wykryją problemy, a następnie zgłoszą je, zanim zmiana zostanie wdrożona. Taki proces dobrze się sprawdza, umożliwiając dynamiczne i adaptacyjne zarządzanie zmianami w naszym środowisku. Część „Green Build” naszego podejścia odnosi się do pomyślnej lub czystej kompilacji w naszym procesie CI/CD z uwzględnieniem nowo wprowadzonych zmian. Jeśli zmiana wprowadza składniki, które nie przejdą pomyślnie dowolnego testu integracji, działania, jednostkowego lub zabezpieczeń, kompilacja zostanie odrzucona i powróci do pierwotnego wniosku o zmianę, aby umożliwić rozwiązanie wszelkich problemów.
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 | Zarządzanie zmianami w naszym środowisku | Atlassian Trust Center
Przejście od zapewniania jakości do wspomagania jakości |
| Zasada 6: Bezpieczeństwo personelu |
| | Wartości firmy
Informacje o wartościach firmy Atlassian są dostępne tutaj: https://www.atlassian.com/company/values
| Wartości firmy
Wartości firmy | Atlassian
|
| Sprawdzanie przeszłości pracownikó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. | Sprawdzanie przeszłości pracowników
Sprawdzanie przeszłości pracowników | Atlassian Trust Center |
| Szkolenia z zakresu bezpieczeństwa dla wszystkich pracowników Atlassian
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. Zwiększanie świadomości w zakresie bezpieczeństwa | Atlassian Trust Center | Szkolenia z zakresu bezpieczeństwa dla wszystkich pracowników firmy Atlassian
Zwiększanie świadomości w zakresie bezpieczeństwa | Atlassian Trust Center |
| Zasada 7: Bezpieczne prowadzenie prac programistycznych | Atlassian stosuje bezpieczne praktyki programistyczne na wszystkich etapach cyklu tworzenia produktów. Więcej informacji można znaleźć pod adresem: 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 odpowiednie 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 wiodący w branży program wykrywania błędów (Program wykrywania błędów Atlassian | Bugcrowd), aby bezpieczeństwo naszych aplikacji było stale poddawane kontroli.
Ponadto można zapoznać się z raportem SOC 2 firmy Atlassian. Celem raportu jest ocena systemów organizacji pod kątem bezpieczeństwa, dostępności, integralności przetwarzania, poufności i prywatności. | Aneks dotyczący przetwarzania danych | Atlassian Trust Center |
| Zasada 8: Bezpieczeństwo łańcucha dostaw | Jeśli Atlassian angażuje jakichkolwiek dostawców zewnętrznych (w tym podwykonawców i dostawców usług w chmurze), staramy się, aby takie przedsięwzięcia w żaden sposób nie narażały na ryzyko naszych klientów ani ich danych. W związku z tym każdy proponowany angaż dostawcy zewnętrznego jest poddawany analizie przeprowadzanej przez nasz zespół prawny i ds. zaopatrzenia. W przypadku przedsięwzięć, z którymi wiąże się krytyczne lub wysokie ryzyko, są one dodatkowo analizowane przez zespoły ds. zabezpieczeń, ryzyka i zgodności. Z należytą starannością przeprowadzane są również kolejne weryfikacje — podczas odnawiania umowy lub co roku, w zależności od poziomu ryzyka, jakie stwarza zaangażowanie dostawcy.
Ponadto Atlassian wymaga od dostawców spełnienia minimalnych wymagań dotyczących bezpieczeństwa w ramach ich współpracy z nami. Są one egzekwowane poprzez włączenie ich do naszych umów z dostawcami. Te wymagania różnią się w zależności od poziomu ryzyka przedsięwzięcia i obejmują:
- integrację protokołu SAML z platformą logowania jednokrotnego Atlassian;
- szyfrowanie danych podczas przesyłania i magazynowania przy użyciu aktualnych algorytmów;
- wdrożenie mechanizmów rejestrowania wystarczających do udostępnienia Atlassian istotnych informacji dotyczących potencjalnych incydentów związanych z bezpieczeństwem.
| Zarządzanie ryzykiem dostawców | Atlassian Trust Center
Atlassian SOC 2 | Strona 29 (Zarządzanie dostawcami) |
| Zasada 9: Bezpieczne zarządzanie użytkownikami |
| 9.1 Uwierzytelnianie użytkowników w interfejsach zarządzania i kanałach wsparcia | W firmie Atlassian jesteśmy przekonani, że to wspólna odpowiedzialność spoczywająca zarówno na kliencie, jak i naszej firmie.
Uwierzytelnieni użytkownicy
Wszystkie dane naszych klientów traktujemy jako równie wrażliwe, dlatego wdrożyliśmy rygorystyczne środki kontroli w zakresie administrowania tymi danymi. W trakcie procesu wdrażania do pracy nasi pracownicy wewnętrzni i podwykonawcy uczestniczą w szkoleniu, którego celem jest zwiększenie świadomości o najlepszych praktykach przetwarzania danych klientów oraz ważności tych praktyk.
W Atlassian dostęp do danych klienta przechowywanych w naszych aplikacjach mają wyłącznie upoważnieni pracownicy Atlassian. Uwierzytelnianie odbywa się za pośrednictwem indywidualnych kluczy publicznych chronionych hasłem, a serwery akceptują wyłącznie połączenia przychodzące SSH z lokalizacji Atlassian i wewnętrznych centrów danych. Dostęp jest ograniczony do grup posiadających odpowiednie uprawnienia, o ile wniosek o dostęp nie zostanie wysłany i pomyślnie zweryfikowany, z wymaganiem dodatkowego uwierzytelniania dwuskładnikowego.
Rygorystyczne kontrole uwierzytelniania i autoryzacji ułatwiają naszemu globalnemu zespołowi wsparcia realizację procesów obsługi i pomocy technicznej. Dostęp do hostowanych aplikacji oraz danych jest uzyskiwany wyłącznie w celu monitorowania stanu aplikacji oraz przeprowadzenia konserwacji systemu lub aplikacji, bądź na wniosek klienta przesłany za pośrednictwem naszego systemu wsparcia. Udzielając wyraźnej zgody, nasi klienci mają również możliwość wskazania, którzy inżynierowie wsparcia mogą uzyskać dostęp do ich danych za pośrednictwem naszego narzędzia Consent Control Checker.
Nieuprawniony lub niewłaściwy dostęp do danych klienta jest traktowany jako incydent dotyczący bezpieczeństwa i objęty procesem zarządzania incydentami. Ten proces uwzględnia instrukcje powiadamiania klientów, których dotyczy incydent, o zaobserwowaniu przypadku naruszenia zasad. | Kontrola dostępu do danych klientów | Atlassian Trust Center
Aneks dotyczący przetwarzania danych | Atlassian Trust Center |
| 9.2 Separacja i kontrola dostępu w interfejsach zarządzania | Wykorzystujemy tę architekturę AWS do hostowania wielu usług platformowych i produktowych stosowanych w naszych rozwiązaniach. Dotyczy to funkcji platformy, które są współdzielone i stosowane w wielu produktach Atlassian, takich jak Media, Identity i Commerce, środowisk, takich jak nasz Editor, a także możliwości specyficznych dla konkretnego produktu, takich jak usługa zgłoszeń Jira i analizy Confluence.
Programiści firmy Atlassian świadczą te usługi poprzez wewnętrznie opracowaną platformę jako usługę (PaaS), zwaną Micros, która automatycznie organizuje wdrażanie usług współdzielonych, infrastruktury, magazynów danych i ich możliwości zarządzania, w tym wymogów w zakresie bezpieczeństwa i kontroli zgodności (zob. rysunek 1 powyżej). Zazwyczaj produkt Atlassian składa się z wielu usług „kontenerowych”, które są wdrażane w AWS za pomocą Micros. Produkty Atlassian wykorzystują podstawowe możliwości platformy (patrz rysunek 2 poniżej), od routingu wniosków po magazyny obiektów binarnych, uwierzytelnianie/autoryzację, transakcyjne magazyny treści generowanych przez użytkowników (UGC) i relacji między jednostkami, jeziora danych, wspólne rejestrowanie, śledzenie wniosków, obserwowalność i usługi analityczne.
Wykorzystując naszą infrastrukturę chmurową, zbudowaliśmy i utrzymujemy wielodostępną architekturę mikrousług ze współdzieloną platformą do obsługi naszych produktów. W architekturze z wielodostępem pojedyncza usługa obsługuje wielu klientów, w tym bazy danych i instancje obliczeniowe wymagane do uruchamiania naszych produktów chmurowych. Każdy shard (zasadniczo kontener — patrz rysunek 3 poniżej) zawiera dane wielu dzierżawców, jednak dane każdego dzierżawcy są odizolowane i niedostępne dla innych dzierżawców. Należy pamiętać, że nie oferujemy architektury z pojedynczym dostępem.
Więcej informacji można znaleźć na stronie https://www.atlassian.com/trust/reliability/cloud-architecture-and-operational-practices#cloud-infrastructure | Architektura z wielodostępem | Praktyki operacyjne i architektura Atlassian Cloud
Aneks dotyczący przetwarzania danych | Atlassian Trust Center |
| Zasada 10: Tożsamość i uwierzytelnianie |
| | Więcej informacji na temat uwierzytelniania i zarządzania dostępem można znaleźć w pkt. 9.1 i 9.2. | Nie dotyczy |
| Zasada 11: Ochrona interfejsów zewnętrznych |
| | Więcej informacji na temat ochrony, jaką Atlassian Trust zapewnia naszym klientom korzystającym z usług w chmurze zawiera Zasada 5. | Nie dotyczy |
| Zasada 12: Bezpieczne administrowanie usługami |
| | W Aneksie dotyczącym przetwarzania danych firmy Atlassian zobowiązujemy się do ochrony danych klientów, w tym kontroli dostępu i zarządzania uprawnieniami.
Więcej informacji na temat uwierzytelniania i zarządzania dostępem można znaleźć w pkt. 9.1 i 9.2. | Nie dotyczy |
| Zasada 13: Dane audytu dla użytkowników |
| | Cały dostęp do aplikacji klienta jest rejestrowany. Każda interakcja z interfejsem użytkownika jest rejestrowana w dzienniku audytu aplikacji.
Firma Atlassian ogranicza, rejestruje i monitoruje dostęp uprzywilejowany do naszego magazynu tożsamości kont Atlassian oraz innych systemów zarządzania bezpieczeństwem informacji.
Dzienniki są przechowywane w logicznie oddzielnym systemie, a dostęp do zapisu w dziennikach jest ograniczony do członków zespołu ds. bezpieczeństwa. W przypadku zidentyfikowania określonych czynności lub zdarzeń w dziennikach do zespołu ds. bezpieczeństwa lub centrum obsługi wysyłane są alerty. Nasza scentralizowana usługa rejestrowania (obejmująca platformę Atlassian Cloud, system Jira, Confluence i Bamboo) jest zintegrowana z naszą infrastrukturą analizy zabezpieczeń w celu przeprowadzania automatycznych analiz i generowania alertów pozwalających zidentyfikować potencjalne problemy.
W przypadku Bitbucket dzienniki audytu wykorzystuje się w badaniach przeprowadzanych po incydentach. Konfiguracja usług zarządzana przy użyciu aplikacji Puppet dzięki deklaratywnemu formatowi sprawia, że wszystkie konfiguracje systemu zarządzane przez manifesty tej aplikacji są poprawnie skonfigurowane przy każdym uruchomieniu. Jeśli nie uda się uruchomić aplikacji Puppet na danym serwerze, generowane są alerty monitorowania. Nasze skanery wewnętrznych i zewnętrznych luk w zabezpieczeniach ostrzegają o wszelkich niespodziewanych otwartych portach lub innych zmianach w konfiguracji (np. profilach TLS nasłuchujących serwerów).
Więcej informacji można znaleźć w sekcji poświęconej usłudze Atlassian Access: Atlassian Access | Bezpieczeństwo i logowanie jednokrotne w Jira, Confluence itp.
Na poziomie wewnętrznym w firmie Atlassian dzienniki są przechowywane w systemie odrębnym pod względem logicznym, a uprawnienia do zapisu w dziennikach są ograniczone do członków zespołu ds. zabezpieczeń oraz naszego zespołu ds. wglądu w systemy. Nasza scentralizowana usługa rejestrowania jest zintegrowana z naszą infrastrukturą analizy zabezpieczeń w celu przeprowadzania automatycznych analiz i generowania alertów pozwalających zidentyfikować potencjalne problemy.
Dla klientów Atlassian Cloud dzienniki audytu obejmujące zmiany w organizacji są dostępne w ramach usługi Atlassian Access. Dzięki dziennikom audytu można uzyskać wgląd w działania administratorów związane z użytkownikami, grupami, uprawnieniami itp. Więcej informacji można znaleźć tutaj: https://support.atlassian.com/security-and-access-policies/docs/track-organization-activities-from-the-audit-log/
Produkty Atlassian Cloud mają również własne dzienniki audytu, w których są rejestrowane zmiany właściwe dla danego produktu. | Nie dotyczy |
| Zasada 14: Bezpieczne korzystanie z usługi |
| | W firmie Atlassian jesteśmy przekonani, że to wspólna odpowiedzialność spoczywająca zarówno na kliencie, jak i naszej firmie.
W niniejszym artykule odnosimy się do wielu innych zasobów, z którymi również można się zapoznać, aby uzyskać więcej informacji na temat naszego podejścia do zarządzania lukami w zabezpieczeniach i do bezpieczeństwa w ogóle.
| Nie dotyczy |