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