Zasady usuwania błędów zabezpieczeń
Ochrona systemów klienta przed atakami z wykorzystaniem luk w zabezpieczeniach produktów Atlassian jest dla nas sprawą priorytetową.
Zakres
Poniżej opisano, w jaki sposób i kiedy usuwamy błędy zabezpieczeń w naszych produktach. Nie jest to opis pełnego procesu ujawniania lub doradztwa, który stosujemy.
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 ramy czasowe:
Ramy czasowe usuwania błędów w trybie przyspieszonym
Przedstawione poniżej ramy czasowe dotyczą wszystkich produktów chmurowych Atlassian, a także dowolnego innego oprogramowania lub systemu zarządzanego przez Atlassian bądź działającego w oparciu o infrastrukturę Atlassian. Mają one również zastosowanie do rozwiązania Jira Align (zarówno w wersji Cloud, jak i w wersjach samodzielnie zarządzanych).
- Błędy krytyczne — usunięcie z produktu w ciągu 2 tygodni od weryfikacji.
- Błędy bardzo istotne — usunięcie z produktu w ciągu 4 tygodni od weryfikacji.
- Błędy średnio istotne — usunięcie z produktu w ciągu 6 tygodni od weryfikacji.
- Błędy mało istotne — usunięcie z produktu w ciągu 25 tygodni od weryfikacji.
Ramy czasowe usuwania błędów w trybie wydłużonym
Przedstawione poniżej ramy czasowe dotyczą wszystkich samodzielnie zarządzanych produktów Atlassian. Produkt samodzielnie zarządzany jest instalowany przez klientów w systemach przez nich zarządzanych i obejmuje aplikacje serwerowe, do centrów danych, komputerowe i mobilne Atlassian.
- Błędy krytyczne, bardzo istotne i średnio istotne — usunięcie z produktu w ciągu 90 dni od weryfikacji.
- Błędy mało istotne — usunięcie z produktu w ciągu 180 dni od weryfikacji.
Krytyczne luki w zabezpieczeniach
W przypadku wykrycia przez Atlassian lub zgłoszenia przez stronę trzecią krytycznej luki w zabezpieczeniach, Atlassian podejmie następujące kroki:
- Możliwie jak najszybciej udostępni nowe, poprawione wydanie bieżącej wersji produktu, którego dotyczy problem.
- Opublikuje nowe wydanie poprawiające poprzednią wersję zgodnie z następującym schematem:
Produkt | Zasady backportowania | Przykład |
|---|---|---|
| Jira Software Server i Data Center Jira Core Server i Data Center Jira Service Management Server i Data Center (dawniej Jira Service Desk) | Udostępnienie nowych wydań z poprawką błędu dla:
| 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 Server i Data Center | Udostępnienie nowych wydań z poprawką błędu dla:
| 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 Server i Data Center | Udostępnienie nowych wydań z poprawką błędu dla:
| 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.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. |
| 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:
|
Produkt | Zasady backportowania | Przykład |
|---|---|---|
| Jira Software Server i Data Center Jira Core Server i Data Center Jira Service Management Server i Data Center (dawniej Jira Service Desk) Confluence Server i Data Center Bitbucket Server i Data Center Bamboo Server i Data Center | Udostępnienie nowych wydań z poprawką błędu dla:
| Jeśli krytyczna poprawka zabezpieczeń została opracowana 1 stycznia 2020 roku, otrzymają ją przykładowo następujące wydania:
Poniżej przedstawiono przykłady wydań, które nie otrzymają wówczas poprawek błędów:
|
| 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 Crowd została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:
|
ProduktJira Software Server i Data Center Jira Core Server i Data Center Jira Service Desk Server i Data Center |
Zasady backportowaniaUdostępnienie nowych wydań z poprawką błędu dla:
|
PrzykładPrzykł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:
|
ProduktConfluence Server i Data Center |
Zasady backportowaniaUdostępnienie nowych wydań z poprawką błędu dla:
|
PrzykładPrzykł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:
|
ProduktBitbucket Server i Data Center |
Zasady backportowaniaUdostępnienie nowych wydań z poprawką błędu dla:
|
PrzykładPrzykł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.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. |
Produkt |
Zasady backportowaniaUdostępnienie nowych wydań z poprawką błędu jedynie dla bieżącej i poprzedniej wersji wydania z funkcjami. |
PrzykładPrzykł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:
|
Ważne, aby korzystać z najnowszego wydania z poprawkami błędów używanej wersji produktu (jest to najlepsza praktyka). Przykładowo klienci korzystający z rozwiązania Jira Software 7.5.0, powinni proaktywnie dokonać uaktualnienia do wersji Jira Software 7.5.3. W przypadku wydania nowej poprawki zabezpieczeń, np. Jira Software 7.5.4, różnica między dwoma wersjami będzie minimalna (tj. będzie to wyłącznie poprawka zabezpieczeń), co ułatwi jej zastosowanie.
Proces eliminowania krytycznych luk w zabezpieczeniach nie ma zastosowania do produktów Atlassian Cloud, ponieważ poprawki w tych usługach są zawsze wprowadzane przez Atlassian, bez konieczności podejmowania jakichkolwiek działań przez klientów.
Niekrytyczne luki w zabezpieczeniach
W przypadku wykrycia bardzo istotnych, średnio istotnych lub mało istotnych problemów z zabezpieczeniami 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, możliwe jest również backportowanie poprawki do wersji ze wsparciem długoterminowym.
Po udostępnieniu wydania z poprawką błędu należy uaktualnić instalacje, aby mieć pewność, że zostały zastosowane najnowsze poprawki zabezpieczeń.
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.