Jak zachować bezpieczeństwo repozytorium GitHub
W tym miejscu omawiamy niektóre z najważniejszych narzędzi i technik dotyczących zabezpieczeń dostępnych dla administratorów repozytorium usługi GitHub.
Uwaga
Poniższa zawartość nie obejmuje podstaw pisania bezpiecznego kodu, ale raczej ważnych zagadnień dotyczących zabezpieczeń, narzędzi i funkcji do użycia w repozytorium GitHub.
Znaczenie strategii bezpiecznego programowania
Bezpieczeństwo aplikacji jest ważne. Usługi informacyjne często opowiadają o naruszeniu systemów firmy i prywatnych danych firmowych i klientów, które zostały skradzione.
Co więc należy wziąć pod uwagę podczas planowania strategii bezpiecznego programowania? Oczywiście musimy chronić informacje przed ujawnieniem osobom, które nie powinny mieć do niego dostępu, ale co ważniejsze, musimy zapewnić, że informacje są zmieniane lub niszczone tylko wtedy, gdy są one odpowiednie.
Musimy upewnić się, że prawidłowo uwierzytelniamy, kto uzyskuje dostęp do danych i że mają odpowiednie uprawnienia do tego celu. Za pomocą danych historycznych lub archiwalnych lub dzienników musimy znaleźć dowody, gdy coś jest nie tak.
Istnieje wiele aspektów tworzenia i wdrażania bezpiecznych aplikacji. Oto trzy kwestie, które należy wziąć pod uwagę:
Istnieje ogólny problem z wiedzą: wielu deweloperów i innych pracowników zakłada, że rozumieją bezpieczeństwo, ale nie. Cyberbezpieczeństwo to nieustannie rozwijająca się dyscyplina. Niezbędny jest program ciągłej edukacji i szkoleń.
Kod musi zostać utworzony poprawnie i bezpiecznie: musimy mieć pewność, że kod został utworzony poprawnie i bezpiecznie implementuje wymagane funkcje. Musimy również upewnić się, że funkcje zostały zaprojektowane z myślą o zabezpieczeniach.
Aplikacje muszą być zgodne z regułami i przepisami: musimy upewnić się, że kod jest zgodny z wymaganymi regułami i przepisami. Musimy przetestować zgodność podczas kompilowania kodu, a następnie okresowo testować, nawet po wdrożeniu.
Zabezpieczenia na każdym etapie
Zabezpieczenia nie są czymś, co można dodać później do aplikacji lub systemu. Bezpieczne programowanie musi być częścią każdego etapu cyklu życia tworzenia oprogramowania. Ta koncepcja jest jeszcze ważniejsza w przypadku krytycznych aplikacji i aplikacji, które przetwarzają poufne lub wysoce poufne informacje.
W praktyce, aby trzymać zespoły do odpowiedzialności za to, co opracowują, procesy muszą przejść w lewo lub zostać ukończone wcześniej w cyklu projektowania. Dzięki przeniesieniu działań z końcowego etapu wdrażania do wcześniejszego występuje mniejsza liczba błędów, a deweloperzy mogą przyspieszyć swoje działania.
Pojęcia dotyczące zabezpieczeń aplikacji nie były przedmiotem zainteresowania deweloperów w przeszłości. Oprócz kwestii edukacyjnych i szkoleniowych, wynika to z faktu, że ich organizacje podkreślały szybki rozwój funkcji.
Wraz z wprowadzeniem praktyk DevOps testowanie zabezpieczeń jest jednak łatwiejsze do zintegrowania z potokiem. Testy bezpieczeństwa nie powinny być zadaniem wykonywanym przez specjalistów ds. bezpieczeństwa, lecz stanowić część codziennych procesów dostarczania.
Ogólnie rzecz biorąc, gdy czas ponownej pracy jest brany pod uwagę, dodanie zabezpieczeń do praktyk DevOps wcześniej w cyklu życia programowania umożliwia zespołom deweloperów przechwytywanie problemów wcześniej. Wcześniejsze przechwytywanie problemów może skrócić całkowity czas opracowywania oprogramowania o jakości.
Przesunięcie w lewo to zmiana procesu, ale nie jest to pojedyncze narzędzie ani kontrolka. Chodzi o to, aby wszystkie zabezpieczenia były bardziej skoncentrowane na deweloperach i przesyłały deweloperom opinie na temat zabezpieczeń tam, gdzie są.
Funkcje kart zabezpieczeń
Usługa GitHub oferuje funkcje zabezpieczeń, które pomagają zapewnić bezpieczeństwo danych w repozytoriach i organizacjach. Aby zlokalizować kartę zabezpieczeń:
Na GitHub.com przejdź do strony głównej repozytorium.
W obszarze nazwy repozytorium wybierz pozycję Zabezpieczenia.
Na karcie Zabezpieczenia możesz dodawać funkcje do przepływu pracy usługi GitHub, aby uniknąć luk w zabezpieczeniach w repozytorium i bazie kodu. Do tych funkcji należą:
- Zasady zabezpieczeń, które umożliwiają określenie sposobu zgłaszania luk w zabezpieczeniach w projekcie przez dodanie
SECURITY.mdpliku do repozytorium. - Alerty dependabot, które powiadamiają o wykryciu, że repozytorium korzysta z zależności lub złośliwego oprogramowania narażonego na zagrożenia.
- Biuletyny zabezpieczeń, których można używać do prywatnego omawiania, naprawiania i publikowania informacji o lukach w zabezpieczeniach w repozytorium.
- Skanowanie kodu, które ułatwia znajdowanie, klasyfikowanie i naprawianie luk w zabezpieczeniach i błędów w kodzie.
Aby uzyskać więcej informacji, zobacz Funkcje zabezpieczeń usługi GitHub.
Uwaga
Biuletyny alertów dependabot dla złośliwego oprogramowania są obecnie w wersji beta i mogą ulec zmianie. Alerty Dependabot wyzwalają tylko doradcy, które zostały przejrzene przez usługę GitHub.
Następnie zapoznamy się z niektórymi z tych funkcji i poznamy sposoby dystrybucji obowiązków związanych z zabezpieczeniami i operacjami we wszystkich fazach cyklu życia tworzenia oprogramowania.
Komunikowanie zasad zabezpieczeń za pomocą SECURITY.md
Korzyści społeczności usługi GitHub są istotne, ale również niosą ze sobą potencjalne zagrożenia. To, że każdy może publicznie proponować poprawki błędów, wiąże się z pewną odpowiedzialnością. Najważniejsze jest odpowiedzialne ujawnienie informacji, które może prowadzić do luk w zabezpieczeniach, zanim możliwa będzie naprawa ich podstawowych błędów. Deweloperzy chcący raportować lub rozwiązywać problemy dotyczące zabezpieczeń poszukają pliku SECURITY.md w katalogu głównym repozytorium, aby odpowiedzialnie ujawnić swoje obawy. Dostarczanie wskazówek w tym pliku ostatecznie przyspiesza rozwiązywanie tych krytycznych problemów.
Aby dowiedzieć się więcej na temat pliku SECURITY.md, zobacz Dodawanie zasad zabezpieczeń do repozytorium.
Biuletyny zabezpieczeń usługi GitHub
Biuletyny zabezpieczeń usługi GitHub umożliwiają konserwatorów repozytorium prywatne omawianie i naprawianie luki w zabezpieczeniach w projekcie. Gdy osoby odpowiedzialne za repozytorium współpracują nad poprawką, mogą publikować porady dotyczące zabezpieczeń, aby publicznie ujawnić lukę w zabezpieczeniach społeczności projektu. Publikując biuletyny zabezpieczeń, osoby odpowiedzialne za repozytorium ułatwiają społeczności aktualizowanie zależności pakietów i badanie konsekwencji luk w zabezpieczeniach. Usługa GitHub przechowuje opublikowane biuletyny na liście Common Vulnerabilities and Exposures (CVE). Ta lista jest używana do automatycznego powiadamiania repozytoriów, których dotyczy problem, korzystających z oprogramowania, które ma wymienioną lukę w zabezpieczeniach. Aby uzyskać więcej informacji, zobacz About repository security advisories (Informacje o biuletynach zabezpieczeń repozytorium).
Przechowywanie poufnych plików poza repozytorium za pomocą polecenia .gitignore
Deweloperzy mogą łatwo przeoczyć pliki zawarte w zatwierdzeniu. Czasami te pomijane pliki są nieszkodliwe, jak na przykład pośrednie pliki kompilacji. Jednak zawsze istnieje ryzyko, że ktoś może przypadkowo zatwierdzić poufne dane. Na przykład ktoś może zatwierdzić klucz interfejsu API lub prywatne dane konfiguracji, których może użyć złośliwy aktor. Jedną z technik, które pomagają uniknąć tego ryzyka, jest tworzenie i konserwowanie .gitignore plików. Te pliki instruują narzędzia klienckie, takie jak wiersz polecenia git w celu ignorowania ścieżek i wzorców podczas agregowania plików do zatwierdzenia.
Poniższy przykład ilustruje niektóre typowe przypadki użycia dla ignorowania plików:
# User-specific files - Ignore all files ending in ".suo"
*.suo
# Mono auto generated files - Ignore all files starting with "mono_crash."
mono_crash.*
# Build results - Ignore all files in these folders found at any folder depth
[Dd]ebug/
[Rr]elease/
x64/
x86/
# Root config folder - Ignore this directory at the root due to leading slash
# Removing the slash would ignore "config" directories at all depths
/config
# Ignore intermediate JS build files produced during TypeScript build at any
# folder depth under /Web/TypeScript. This won't ignore JS files elsewhere.
/Web/TypeScript/**/*.js
Repozytorium może zawierać wiele .gitignore plików. Ustawienia są dziedziczone z katalogów nadrzędnych, a zastępowanie pól w nowych plikach .gitignore ma pierwszeństwo przed ustawieniami nadrzędnymi dla ich folderów i podfolderów. Jest to znaczny wysiłek, aby zachować plik główny.gitignore, chociaż dodanie .gitignore pliku do katalogu projektu może być przydatne, gdy ten projekt ma określone wymagania, które są łatwiejsze do utrzymania oddzielnie od elementu nadrzędnego, takie jak pliki, które nie powinny być ignorowane.
Aby dowiedzieć się więcej na ten temat pliku .gitignore, zobacz Ignorowanie plików. Sprawdź również kolekcję plików startowych .gitignore dostępnych dla różnych platform w repozytorium gitignore.
Usuwanie poufnych danych z repozytorium
Chociaż .gitignore pliki mogą być przydatne w pomaganiu współautorom w unikaniu zatwierdzania poufnych danych, jest to tylko silna sugestia. Deweloperzy mogą nadal obejść ten proces, aby dodać pliki, jeśli są wystarczająco zmotywowani, a czasami pliki mogą się prześlizgnąć, ponieważ nie spełniają .gitignore konfiguracji pliku. Uczestnicy projektu zawsze powinni znajdować się w poszukiwaniu zatwierdzeń zawierających dane, które nie powinny być uwzględnione w repozytorium ani jego historii.
Ważne
Należy założyć, że wszystkie dane zatwierdzone w usłudze GitHub w dowolnym momencie zostały naruszone. Po prostu zastąpienie zatwierdzenia nie wystarczy, aby upewnić się, że dane nie będą dostępne w przyszłości. Aby uzyskać kompletny przewodnik dotyczący usuwania poufnych danych z usługi GitHub, zobacz Usuwanie poufnych danych z repozytorium.
Reguły ochrony gałęzi
Regułę ochrony gałęzi można utworzyć, aby wymusić określone przepływy pracy dla co najmniej jednej gałęzi. Na przykład można wymagać zatwierdzenia przeglądu lub przekazania kontroli stanu dla wszystkich żądań ściągnięcia scalonych z chronioną gałęzią.
Możesz użyć przepływów pracy, które chronią gałąź, aby:
- Uruchamianie kompilacji w celu sprawdzenia, czy można skompilować zmiany kodu
- Uruchom linter, aby sprawdzić pisownię i zgodność z wewnętrznymi konwencjami kodowania
- Uruchamianie testów automatycznych w celu sprawdzenia, czy nie wprowadzono zmian zachowania kodu
- i tak dalej
Dodawanie pliku CODEOWNERS
Dodając plik CODEOWNERS do repozytorium, możesz przypisać poszczególnych członków zespołu lub całe zespoły jako właścicieli kodu do ścieżek w repozytorium. Ci właściciele kodu są następnie zobowiązani do przeglądów żądań ściągnięcia na wszelkie zmiany w plikach w ścieżce, dla której są skonfigurowane.
# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js @js-owner
# Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocat
Plik CODEOWNERS można utworzyć w katalogu głównym repozytorium lub w folderze docs lub .github .