GitHub Apps na poziomie enterprise: bezpieczniejsza alternatywa dla klasycznych PAT

GitHub ogłosił ogólną dostępność instalowania GitHub Apps na poziomie enterprise. Rozszerzone uprawnienia i pokrycie API pozwalają zastąpić klasyczne tokeny dostępu osobistego (PAT) w większej liczbie automatyzacji zarządczych i bezpieczeństwa obejmujących wiele organizacji.

Nowe możliwości obejmują między innymi polityki repozytoriów, rulesety, żądania obejścia reguł, wymagania uwierzytelniania dwuskładnikowego, weryfikowane domeny, listy dozwolonych adresów IP i ograniczenia dostępu do enterprise. GitHub Apps mogą też zarządzać ustawieniami uprawnień członków i repozytoriów.

Wniosek Breachroad: migracja z PAT do GitHub App poprawia rozliczalność i daje lepszą kontrolę zakresu, ale sama nazwa mechanizmu nie gwarantuje least privilege. Aplikacja z uprawnieniami do polityk, 2FA i IP allowlist jest uprzywilejowaną tożsamością maszynową, która wymaga równie dojrzałego nadzoru jak konto administratora.

Co GitHub udostępnił

Enterprise może teraz instalować aplikację bez budowania osobnego modelu tożsamości dla każdej organizacji. GitHub rozszerzył uprawnienia w trzech obszarach.

Governance obejmuje zarządzanie politykami repozytoriów i rulesetami na poziomie enterprise oraz odczyt żądań obejścia reguł. Automatyzacja może kontrolować między innymi tworzenie i usuwanie repozytoriów, widoczność, domyślne uprawnienia, forki prywatnych repozytoriów, deploy keys i aktualizacje chronionych gałęzi.

Security obejmuje wymagania 2FA i dozwolone metody uwierzytelniania, weryfikowane domeny, enterprise i organization IP allowlists oraz ograniczenia dostępu. Część operacji pozwala także włączać egzekwowanie listy IP i określać zaufanie do GitHub Apps.

Administration pozwala aktualizować profil enterprise oraz zarządzać uprawnieniami członków i dostępem do repozytoriów. Uzupełniono również część braków istniejących uprawnień dotyczących osób i billing.

GitHub zapowiada te możliwości w GitHub Enterprise Server 3.24.

Dlaczego klasyczny PAT jest problematyczny w automatyzacji

Klasyczny PAT jest powiązany z człowiekiem i często dziedziczy szeroki zakres wynikający z jego roli. Gdy token trafia do skryptu działającego latami, powstaje kilka problemów:

• właściciel zmienia rolę albo odchodzi, a automatyzacja przestaje działać;
• trudno odróżnić operacje człowieka od działania skryptu;
• token ma więcej uprawnień niż konkretny proces potrzebuje;
• rotacja zależy od prywatnego konta i pamięci jednej osoby;
• sekret jest kopiowany między systemami CI/CD, sejfami i dokumentacją;
• incydent wymaga odebrania dostępu człowiekowi i automatyzacji jednocześnie.

GitHub App tworzy oddzielną tożsamość integracji, pozwala wybrać uprawnienia i korzysta z krótkotrwałych tokenów instalacyjnych. To ułatwia przypisanie działań i ograniczenie skutków wycieku.

Nie oznacza to jednak, że każdą automatyzację należy połączyć w jedną „superaplikację”. Kompromitacja centralnej aplikacji z prawem do zmiany reguł, 2FA i list IP może mieć szeroki wpływ na całe enterprise.

Jak zaplanować migrację z PAT

1. Zinwentaryzuj tokeny i ich rzeczywiste zadania

Nie zaczynaj od listy nazw sekretów. Połącz logi audytowe, konfiguracje CI/CD, sejf sekretów i rozmowę z właścicielami procesów. Dla każdego PAT zapisz: właściciela, cel, używane API, organizacje, środowisko, ostatnie użycie i konsekwencję awarii.

2. Podziel automatyzacje według skutku

Odczyt raportów, zarządzanie politykami repozytoriów, zmiana wymagań 2FA i edycja IP allowlist nie powinny automatycznie korzystać z tej samej aplikacji. Rozdział ogranicza blast radius i ułatwia niezależne zatwierdzanie zmian.

3. Nadaj minimalne uprawnienia

W ustawieniach GitHub App wybierz dokładnie te uprawnienia, których wymaga workflow. Jeżeli proces tylko odczytuje żądania obejścia reguł, nie potrzebuje prawa do edycji rulesetów. Jeżeli raportuje stan 2FA, nie powinien móc zmieniać dozwolonych metod.

4. Chroń klucz prywatny i przepływ tokenu

Token instalacyjny jest krótkotrwały, ale musi zostać bezpiecznie uzyskany. Klucz prywatny aplikacji przechowuj w kontrolowanym menedżerze sekretów, ogranicz dostęp procesu, rejestruj użycie i ustal rotację. Nie zapisuj wygenerowanych tokenów w logach zadania.

5. Wprowadź test i rollback

Uruchom nową aplikację najpierw na ograniczonym zakresie. Sprawdź nie tylko sukces standardowego zadania, ale również odmowę operacji spoza zakresu. Dla automatyzacji zmieniającej ustawienia enterprise przygotuj walidację wejścia, zatwierdzenie i bezpieczny rollback.

6. Usuń stary PAT

Migracja kończy się dopiero po unieważnieniu tokenu, usunięciu jego kopii z systemów i potwierdzeniu, że żadne zadanie nadal go nie używa. Pozostawienie PAT „na wszelki wypadek” zachowuje pierwotne ryzyko.

Kontrole dla aplikacji uprzywilejowanej

Aplikacja zmieniająca rulesety, dostęp do repozytoriów, wymagania 2FA lub IP allowlist powinna mieć:

• formalnego właściciela biznesowego i technicznego;
• udokumentowany zakres oraz uzasadnienie każdego uprawnienia zapisu;
• alerty na instalację, zmianę uprawnień i nietypowe operacje;
• zasadę wielu zatwierdzeń dla zmian osłabiających polityki;
• osobne środowisko testowe lub bezpieczny zakres pilotażowy;
• cykliczny przegląd użycia i automatyczne wykrywanie bezczynności;
• plan odwołania aplikacji bez utraty dostępu awaryjnego do enterprise.

Szczególnie ryzykowna jest automatyzacja, która może wyłączyć kontrolę chroniącą samą automatyzację. Jeżeli aplikacja modyfikuje IP allowlist lub rulesety, jej pipeline nie powinien samodzielnie zatwierdzać własnych wyjątków.

Jak mierzyć efekt migracji

Sama liczba zastąpionych PAT nie mówi, czy ryzyko spadło. Lepsze mierniki to:

• liczba klasycznych PAT używanych przez procesy bez człowieka;
• odsetek aplikacji z uprawnieniami zapisu bez aktywnego użycia;
• średni czas życia tokenów używanych przez automatyzację;
• liczba aplikacji bez przypisanego właściciela i daty przeglądu;
• liczba workflow, które mogą zmienić politykę bez dodatkowej akceptacji;
• czas od wycofania procesu do odebrania wszystkich jego poświadczeń.

Fakty źródłowe i wnioski Breachroad

GitHub potwierdza ogólną dostępność instalacji enterprise, nowe uprawnienia dotyczące polityk, rulesetów, bypassów, 2FA, domen, IP allowlist, ograniczeń dostępu, członków i repozytoriów oraz dostępność w GHES 3.24. Producent wskazuje możliwość zastąpienia klasycznych PAT w większej liczbie scenariuszy automatyzacji.

Podział aplikacji według skutku, proces migracji, wymagania kontroli i mierniki są rekomendacjami Breachroad. Połącz je z zarządzaniem sekretami i rotacją oraz zasadami bezpieczeństwa webhooków. Właściciele platform, deweloperzy i security mogą przećwiczyć odpowiedzialności podczas szkoleń cyberbezpieczeństwa dla organizacji, a konfigurację aplikacji zweryfikować przez audyt bezpieczeństwa IT.

Źródło pierwotne: GitHub Changelog — Enterprise installations for GitHub Apps generally available.