Close

Zasady usuwania błędów zabezpieczeń

Ochrona systemów klienta przed atakami z wykorzystaniem luk w zabezpieczeniach produktów Atlassian jest dla Atlassian sprawą priorytetową.


Zakres

W tych zasadach opisano, jak i kiedy usuwamy luki w zabezpieczeniach w naszych produktach.

Usuwanie błędów zabezpieczeń — docelowe poziomy świadczenia usług (SLO)

Atlassian wyznacza docelowe poziomy świadczenia usług dotyczące usuwania luk w zabezpieczeniach na podstawie poziomu istotności problemów z zabezpieczeniami i konkretnego produktu. W przypadku wydawania poprawek zabezpieczeń w naszych produktach zdefiniowaliśmy następujące cele dotyczące ram czasowych:

Cele usuwania błędów w trybie przyspieszonym

Te ramy czasowe dotyczą:

  • Wszystkich produktów chmurowych Atlassian
  • Każdego oprogramowania lub systemu zarządzanego przez Atlassian
  • Każdego oprogramowania lub systemu działającego w infrastrukturze Atlassian
  • Jira Align w wersji Cloud i w wersjach samodzielnie zarządzanych

W zależności od poziomu podatności zdefiniowaliśmy następujące terminy zastosowania poprawki w produkcie po weryfikacji:

  • Problemy na poziomie krytycznym należy naprawić w ciągu 10 dni.
  • Problemy na poziomie wysokim należy naprawić w ciągu 28 dni.
  • Problemy na poziomie średnim należy naprawić w ciągu 84 dni.
  • Problemy na poziomie niskim należy naprawić w ciągu 175 dni.

Czas usuwania błędów w trybie wydłużonym

Przedstawione poniżej cele dotyczące ram czasowych mają zastosowanie do wszystkich produktów Atlassian dla wersji Data Center i aplikacji mobilnych. Produkty dla wersji Data Center są instalowane przez klienta w systemach zarządzanych przez klienta.

  • Luki w zabezpieczeniach o istotności krytycznej, wysokiej i średniej — wprowadzenie poprawek w produkcie w ciągu 90 dni od weryfikacji
  • Luki w zabezpieczeniach o istotności niskiej — wprowadzenie poprawek w produkcie w ciągu 180 dni od weryfikacji

Model wspólnej odpowiedzialności

Chociaż Atlassian dokłada wszelkich starań, aby dostarczać bezpieczne, produkty od momentu ich wydania, opieramy się również na modelu współodpowiedzialności. Ten model wymaga od klientów wdrożenia praktyk, które wykraczają poza samo wdrożenie i obejmują fazy działalności operacyjnej. Niektóre z tych obowiązków obejmują:

  • Obsługę oprogramowania Atlassian w sieciach prywatnych.
  • Zapewnienie terminowego wdrażania poprawek zabezpieczeń po ich wydaniu.
  • Konfigurowanie zapór aplikacji internetowych (WAF), sieci VPN, uwierzytelniania wieloskładnikowego i logowania jednokrotnego.
  • Wdrożenie szyfrowania i kontroli dostępu.
  • Wykonywanie regularnych kopii zapasowych.
  • Przeprowadzanie regularnych audytów bezpieczeństwa.

Krytyczne luki w zabezpieczeniach

W przypadku wykrycia przez Atlassian lub zgłoszenia przez stronę trzecią krytycznej luki w zabezpieczeniach Atlassian podejmie następujące działania:

  • W przypadku produktów Cloud dostarczymy nową poprawioną wersję dotkniętego produktu tak szybko, jak to możliwe.
  • W przypadku produktów samodzielnie zarządzanych:
    • dostarczymy wydanie z poprawką błędu dla najnowszego wydania z funkcjami dotkniętego produktu;
    • dostarczymy nowe wydanie z funkcjami dla dotkniętego produktu zgodnie z harmonogramem wydań;
    • dostarczymy wydanie z poprawką błędu dla wszystkich obsługiwanych wydań LTS dotkniętego produktu zgodnie z polityką dotyczącą zakończenia wsparcia Atlassian.

Produkt
Zasady backportowania
Przykład

Jira Software Server i Data Center

Jira Server i Data Center

Jira Service Management Server i Data Center (dawniej Jira Service Desk)

Udostępnienie nowych wydań z poprawką błędu dla:

  • Dowolnych wersji oznaczonych jako „wersja ze wsparciem długoterminowym”, dla których okres wsparcia nie dobiegł jeszcze końca.
  • Wszystkich wersji z funkcjami wydanych w ciągu 6 miesięcy od daty udostępnienia poprawki.

Przykładowo, jeśli krytyczna poprawka zabezpieczeń została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:

  • Jira 8.6.x, ponieważ wersja 8.6.0 została wydana 17 grudnia 2019 roku
  • Jira 8.5.x, ponieważ wersja 8.5.0 została wydana 21 października 2019 roku
  • Jira 8.4.x, ponieważ wersja 8.4.0 została wydana 9 września 2019 roku
  • Jira 8.3.x, ponieważ wersja 8.3.0 została wydana 22 lipca 2019 roku
  • Jira 7.13.x, ponieważ 7.13 to wersja ze wsparciem długoterminowym, a wersja 7.13.0 została wydana 28 listopada 2018 roku

Confluence Server i Data Center

Udostępnienie nowych wydań z poprawką błędu dla:

  • Dowolnych wersji oznaczonych jako „wersja ze wsparciem długoterminowym”, dla których okres wsparcia nie dobiegł jeszcze końca.
  • Wszystkich wersji z funkcjami wydanych w ciągu 6 miesięcy od daty udostępnienia poprawki.

Przykładowo, jeśli krytyczna poprawka zabezpieczeń została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:

  • Confluence 7.2.x, ponieważ wersja 7.2.0 została wydana 12 grudnia 2019 roku
  • Confluence 7.1.x, ponieważ wersja 7.1.0 została wydana 4 listopada 2019 roku
  • Confluence 7.0.x, ponieważ wersja 7.0.0 została wydana 10 września 2019 roku
  • Confluence 6.13.x, ponieważ 6.13 to wersja ze wsparciem długoterminowym, a wersja 6.13.0 została wydana 4 grudnia 2018 roku

Bitbucket Server i Data Center

Udostępnienie nowych wydań z poprawką błędu dla:

  • Dowolnych wersji oznaczonych jako „wersja ze wsparciem długoterminowym”, dla których okres wsparcia nie dobiegł jeszcze końca.
  • Wszystkich wersji z funkcjami wydanych w ciągu 6 miesięcy od daty udostępnienia poprawki.

Przykładowo, jeśli krytyczna poprawka zabezpieczeń została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:

  • Bitbucket 6.9.x, ponieważ wersja 6.9.0 została wydana 10 grudnia 2019 roku
  • Bitbucket 6.8.x, ponieważ wersja 6.8.0 została wydana 6 listopada 2019 roku
  • Bitbucket 6.7.x, ponieważ wersja 6.7.0 została wydana 1 października 2019 roku
  • Bitbucket 6.6.x, ponieważ wersja 6.6.0 została wydana 27 sierpnia 2019 roku
  • Bitbucket 6.5.x, ponieważ wersja 6.5.0 została wydana 24 lipca 2019 roku

Bitbucket 6.3.0 wydano 14 maja 2019 roku, ponad sześć miesięcy przed datą poprawki. Gdyby ta wersja była oznaczona jako wersja ze wsparciem długoterminowym, utworzono by również wydanie z poprawką błędu.

Wszystkie inne produkty (Bamboo, Crucible, Fisheye itd.)

Udostępnienie nowych wydań z poprawką błędu jedynie dla bieżącej i poprzedniej wersji wydania z funkcjami.

Przykładowo, jeśli krytyczna poprawka zabezpieczeń dla rozwiązania Bamboo została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:

  • Bamboo 6.10.x, ponieważ ta wersja została wydana 17 września 2019 roku i jest bieżącym wydaniem
  • Bamboo 6.9.x, ponieważ wersja 6.9.0 jest poprzednim wydaniem

W przypadku produktów Crowd, Fisheye i Crucible udostępnimy wydanie z poprawką błędu dla najnowszego wydania z funkcjami dotkniętego produktu.

Przykłady poprawek krytycznych luk w zabezpieczeniach dla produktów samodzielnie zarządzanych:

Jeśli poprawka krytycznej luki w zabezpieczeniach została opracowana 1 stycznia 2024 roku, otrzymają ją przykładowo następujące wydania:

Produkt

Przykład

Jira Software

Przykład

Jira Software 9.13.x, ponieważ 9.13.0 jest najnowszym wydaniem z funkcjami.

Przykład

Jira Software 9.12.x, ponieważ 9.12.0 jest najnowszym wydaniem ze wsparciem długoterminowym (LTS).

Przykład

Jira Software 9.4.x, ponieważ 9.4.0 jest poprzednim wydaniem ze wsparciem długoterminowym (LTS).

Jira Service Management

Przykład

Jira Service Management 5.13.x, ponieważ 5.13.0 jest najnowszym wydaniem z funkcjami.

Przykład

Jira Service Management 5.12.x, ponieważ 5.12.0 jest najnowszym wydaniem ze wsparciem długoterminowym (LTS).

Przykład

Jira Service Management 5.4.x, ponieważ 5.4.0 jest drugim najnowszym obsługiwanym wydaniem ze wsparciem długoterminowym (LTS).

Confluence

Przykład

Confluence 8.7.x, ponieważ 8.7.0 jest najnowszym wydaniem z funkcjami.

Przykład

Confluence 8.5.x, ponieważ 8.5.0 jest najnowszym wydaniem ze wsparciem długoterminowym (LTS).

Przykład

Confluence 7.19.x, ponieważ 7.19.0 jest drugim najnowszym obsługiwanym wydaniem ze wsparciem długoterminowym (LTS).

Bitbucket

Przykład

Bitbucket 8.17.x, ponieważ 8.17.0 jest najnowszym wydaniem z funkcjami.

Przykład

Bitbucket 8.9.x, ponieważ 8.9.0 jest najnowszym wydaniem ze wsparciem długoterminowym (LTS).

Przykład

Bitbucket 7.21.x, ponieważ 7.21.0 jest drugim najnowszym obsługiwaną wydaniem ze wsparciem długoterminowym (LTS).

Bamboo

Przykład

Bamboo 9.5.x, ponieważ 9.5.0 jest najnowszym wydaniem z funkcjami.

Przykład

Bamboo 9.2.x, ponieważ 9.2.0 jest najnowszym wydaniem ze wsparciem długoterminowym (LTS).

Crowd

Przykład

Crowd 5.3.x, ponieważ 5.3.0 jest najnowszym wydaniem z funkcjami.

Fisheye/Crucible

Przykład

Fisheye/Crucible 4.8.x, ponieważ 4.8.0 jest najnowszym wydaniem z funkcjami.

Żadne inne wersje produktów nie otrzymają nowych poprawek błędów.

Częste aktualizacje zapewniają bezpieczeństwo instancji produktów. Najlepiej jest pozostać przy najnowszym wydaniu poprawki błędu najnowszego wydania z funkcjami lub wydania LTS produktu.

Niekrytyczne luki w zabezpieczeniach

W przypadku wykrycia problemów z zabezpieczeniami o wysokiej, średniej lub niskiej istotności Atlassian będzie dążyć do wydania poprawki w terminach określonych w docelowych poziomach świadczenia usług wymienionych na początku tego dokumentu. Jeśli jest to wykonalne, poprawka może być również backportowana do wydania ze wsparciem długoterminowym. Na wykonalność backportowania wpływa wiele czynników, w tym między innymi zależności oprogramowania, zmiany architektoniczne i problemy ze zgodnością.

Aby upewnić się, że instalacje zawierają najnowsze poprawki zabezpieczeń, należy je aktualizować za każdym razem, gdy zostanie udostępnione wydanie z poprawkami błędów.

Inne informacje

Poziom istotności luk w zabezpieczeniach jest obliczany na podstawie poziomów istotności problemów z zabezpieczeniami.

Będziemy poddawać nasze zasady ciągłej ewaluacji w oparciu o opinie klientów, a na tej stronie będziemy zamieszczać wszelkie aktualności lub zmiany.

Często zadawane pytania

Czym jest model wspólnej odpowiedzialności? Copy link to heading Copied! Pokaż +
  

To umowa między dostawcą, takim jak Atlassian, a jego klientami w celu wdrożenia najlepszych praktyk, które wykraczają poza początkowe wdrożenie i obejmują fazy działalności operacyjnej. Aby uzyskać szczegółowe informacje, zapoznaj się ze stroną Lista kontrolna i wspólne obowiązki związane z bezpieczeństwem wersji Data Center.

Czym jest wydanie ze wsparciem długoterminowym (LTS) (np. Jira 10.3 LTS)? Copy link to heading Copied! Pokaż +
  

Wydania ze wsparciem długoterminowym (LTS) są przeznaczone dla klientów korzystających z wersji Data Center, którzy wolą poświęcić więcej czasu na przygotowanie się do uaktualnień do nowych wydań z funkcjami, ale mimo to chcą otrzymywać poprawki błędów. W przypadku niektórych produktów ich konkretna wersja może być oznaczona jako wydanie ze wsparciem długoterminowym, co oznacza, że poprawki zabezpieczeń będą udostępniane przez cały dwuletni okres wsparcia.

Czym jest wydanie z funkcjami (np. Jira 10.1)? Copy link to heading Copied! Pokaż +
  

Wydanie z funkcjami to wersja, która nie została oznaczona jako wydanie LTS. Zamiast tego zawiera nowe funkcje, zmiany w obsługiwanych platformach (takich jak bazy danych, systemy operacyjne, wersje Git) lub usunięcia funkcji.

Dowiedz się więcej o zasadach usuwania błędów Atlassian.

Czym jest wydanie z poprawkami błędów (np. Jira 10.2.1)? Copy link to heading Copied! Pokaż +
  

Wydania z poprawkami błędów mogą obejmować ulepszenia stabilności i wydajności, a także usuwać błędy funkcjonalności i luki w zabezpieczeniach. W zależności od charakteru poprawek mogą one wprowadzać niewielkie zmiany w istniejących funkcjach. Nie zawierają one jednak nowych funkcji ani zmian wysokiego ryzyka, dzięki czemu można je szybko wdrożyć. Zalecamy niezwłoczną aktualizację bieżącej wersji do najnowszego wydania z poprawkami błędów.

Czym jest wspierane wydanie? Copy link to heading Copied! Pokaż +
  

Atlassian wspiera wydania przez dwa lata po udostępnieniu początkowego wydania z funkcjami lub wydania ze wsparciem długoterminowym (LTS). Przykładowo zapewniamy wsparcie techniczne dla Jira 9.14.x przez dwa lata po wydaniu Jira 9.14.0.

Czym jest luka w zabezpieczeniach? Copy link to heading Copied! Pokaż +
  

Luka w zabezpieczeniach odnosi się do podatności lub wady, które mogą zostać wykorzystane przez zagrożenie lub czynnik ryzyka. W kontekście cyberbezpieczeństwa luka w zabezpieczeniach może być wadą oprogramowania, sieci lub systemu, która umożliwia nieautoryzowanym użytkownikom uzyskanie dostępu i spowodowanie szkód. Może to obejmować nieaktualne oprogramowanie, słabe hasła lub brak szyfrowania danych.

Czym jest poprawka błędu zabezpieczeń? Copy link to heading Copied! Pokaż +
  

Poprawka błędu zabezpieczeń to zestaw zmian wprowadzonych w systemie lub aplikacji w celu wyeliminowania luk w zabezpieczeniach, które mogłyby zostać wykorzystane przez hakerów. Te luki w zabezpieczeniach, nazywane też błędami zabezpieczeń, mogą prowadzić do nieautoryzowanego dostępu, kradzieży danych lub innych szkodliwych działań.

Gdzie mogę znaleźć więcej informacji na temat usuniętych luk w zabezpieczeniach w produktach Data Center? Copy link to heading Copied! Pokaż +
  

Atlassian publikuje comiesięczne Ostrzeżenia dotyczące bezpieczeństwa i oferuje dostęp do Portalu ujawniania luk w zabezpieczeniach. Portal ujawniania luk w zabezpieczeniach to centrum informacji o ujawnionych lukach w każdym z naszych produktów. Jest on aktualizowany co miesiąc wraz z wydaniem każdego Biuletynu bezpieczeństwa i umożliwia łatwe wyszukiwanie danych z poprzednich biuletynów i uzyskiwanie dostępu do nich.