Architektura bezpieczeństwa
Model bezpieczeństwa Exportelier opiera się na celowym podziale na dwie aplikacje, tak aby aplikacja obsługująca dane dotyczące problemów nie miała możliwości ich nigdzie wysłać.
Aplikacja główna: bez pobierania i bez wyzwalaczy internetowych
Główna aplikacja deklaruje no external fetch i no webtriggers w swoim manifeście Forge. Pliki PDF są renderowane w całości na Forge, bez przeglądarki bezgłowej i serwerów innych firm. Jest to egzekwowane przez platformę Atlassian — jest to gwarancja architektury, a nie obietnica polityczna.
Schemat: aplikacja główna (bez wyjścia, renderuje na Forge) wraz z aplikacją Automation (wszystkie wyjścia, izolowane).
Aplikacja do automatyzacji: izolowane wyjście
Wszystko, co musi wysyłać dane na zewnątrz — poczta e-mail, przychodzące webhooki Slack, przepływy pracy Microsoft Teams i API — znajduje się w osobnej aplikacji Exportelier Automation. Przenosi all ruch wychodzący, z ochroną SSRF i tajnymi adresami URL specyficznymi dla dostawcy.
Raporty wpisują Jira jako użytkownika eksportującego
Każde Jira przeczytanie raportu wykonuje — lista Zapisano
Filtry, sprawdzanie ich w fazie wstępnej i wyszukiwanie podczas eksportu — uruchamia się
jako osoba, która to rozpoczęła, używając tożsamości Forge asUser. Aplikacja nigdy
powraca do własnej tożsamości aplikacji, aby eksport w kolejce zakończył się pomyślnie.
Dwie właściwości wynikają bezpośrednio:
- Status administratora witryny w Exportelier nigdy nie zwiększa widoczności Jira. Administrator może zbuduj raport na podstawie filtrów, które widzą; do których nikt inny nie ma dostępu oni. Jeśli źródło nie jest dostępne dla użytkownika eksportującego, eksport **nie powiedzie się i nadaje mu nazwę **, zamiast dyskretnie pomijać źródło danych.
- Żadne zapytanie nie jest nigdy przechowywane ani składane z Twojego tekstu. Exportelier przechowuje
Zapisano numeryczny identyfikator filtra i zbudowano dokładnie jeden ściśle numeryczny predykat,
filter = <id>. Filtr JQL nigdy nie jest odczytywany, przechowywany, rejestrowany ani łączony, więc nie ma powierzchni wtrysku JQL ani nieaktualnej kopii zapytania.
Wynik raportu jest tymczasowy i usuwany po pobraniu – patrz Przechowywanie danych & GDPR.
Import panelu kontrolnego wykorzystuje wyłącznie udokumentowane interfejsy API
Import panelu kontrolnego odczytuje Jira wyłącznie poprzez Atlassian jest udokumentowany Jira Cloud deska rozdzielcza REST API, jako użytkownik importujący. Nie analizuje stron internetowych Jira, nie czyta ramek iframe gadżetów, przechwytuj zrzuty ekranu, używaj nieudokumentowanych punktów końcowych preferencji gadżetów lub wysyłaj cokolwiek poza Forge. Nie wymagało to żadnego nowego zakresu uprawnień.
To, co się czyta, jest celowo zawężone. Sprawdzane są wartości konfiguracyjne gadżetu względem listy dozwolonych dla poszczególnych gadżetów, ograniczonej rozmiarem znacznie poniżej maksymalnego limitu Jira oraz nigdy nie rejestrowane, nie odbijały się na błędach ani nie były zapisywane w celu audytu zdarzeń. Filtr JQL jest nigdy nie przechowywany, nawet jeśli właściwość gadżetu go zawiera — zaimportowany raport zachowuje ten sam numeryczny identyfikator filtra, co każdy inny raport.
Jedna z operacji, Pobierz gadżety, jest oznaczona jako Eksperymentalna Atlassian. Jeśli jego odpowiedź przestanie odpowiadać temu, co Exportelier zweryfikowano względem a prawdziwa witryna Jira, ścieżka importu nie zostaje zamknięta, a funkcja sama się wyłącza zamiast działać w oparciu o błędnie odczytaną odpowiedź. Istniejące raporty i eksporty są nienaruszone.
Rejestr zdarzeń audytu stwierdzający, że rekord importu został sprawdzony lub usunięty. Niosą nr konfiguracja gadżetu, brak JQL i brak danych problemów.
Po co je dzielić
Jeśli Twoje zasady zabraniają ruchu wychodzącego, instalujesz tylko główną aplikację i masz gwarancję, że nic nie opuści Atlassian. Zespoły potrzebujące dostawy świadomie dodają aplikację Automation.
Zobacz także Przestrzeń danych i stronę Zakupy i bezpieczeństwo dostawców.