Omówienie ochrony danych
Azure DevOps Services
Azure DevOps Services to aplikacja hostowana w chmurze dla projektów programistycznych, od planowania przez wdrożenie. Na podstawie możliwości lokalnych, z większą większa większa liczba usług w chmurze, zarządzamy kodem źródłowym, elementami roboczymi, kompilacjami i testami. Usługa Azure DevOps używa infrastruktury paaS (platform as a service) i wielu usług platformy Azure, w tym usługi Azure SQL, w celu zapewnienia niezawodnej, globalnie dostępnej usługi dla projektów deweloperskich.
W tym artykule omówiono kroki, które firma Microsoft podejmuje, aby zapewnić bezpieczeństwo, bezpieczeństwo i prywatne projekty. Opisuje ona rolę, jaką odgrywasz w celu zapewnienia bezpieczeństwa i bezpieczeństwa projektów.
Ten artykuł dotyczy administratorów organizacji i specjalistów IT, którzy codziennie zarządzają zasobami projektu. Jest to najbardziej przydatne dla osób, które już znają usługę Azure DevOps i chcą dowiedzieć się więcej o tym, jak firma Microsoft chroni przechowywane zasoby w usłudze Azure DevOps.
Nasze zobowiązanie
Firma Microsoft pomaga zapewnić bezpieczeństwo i bezpieczeństwo projektów bez wyjątku. Podczas przechowywania projektów w usłudze Azure DevOps korzystają one z wielu warstw technologii zabezpieczeń i ładu, praktyk operacyjnych i zasad zgodności. Wymuszamy prywatność i integralność danych zarówno magazynowanych, jak i przesyłanych.
Zagrożenia, które napotykasz, znajdują się w czterech podstawowych kategoriach: dostępność danych, dostępność usługi, zabezpieczenia usługi i prywatność danych. W tym artykule omówiono konkretne zagrożenia w każdej kategorii i wyjaśniono, co robi usługa Azure DevOps, aby je rozwiązać. Artykuł rozpoczyna się od opisania sposobu przechowywania danych i zarządzania dostępem do danych przez usługę Azure DevOps.
Ochrona danych wymaga aktywnego zaangażowania administratorów i użytkowników, którzy wiedzą, jakie kroki należy podjąć, aby chronić zasoby przed nieautoryzowanym ujawnieniem i manipulowaniem. Należy jawnie udzielać uprawnień do punktów dostępu użytkowników, więc tylko odpowiednie osoby uzyskują dostęp do danych w usłudze Azure DevOps.
Należy wziąć pod uwagę wszystkie dane, które mogą być potencjalnie zagrożone, niezależnie od tego, gdzie są używane lub jak są używane. Ta instrukcja dotyczy zarówno danych przechowywanych w chmurze, jak i danych przechowywanych w prywatnym centrum danych. Ważne jest, aby sklasyfikować dane, jego wrażliwość i ryzyko oraz uszkodzenia, które mogą zostać naruszone. Ponadto kategoryzuj dane względem ogólnych zasad zarządzania zabezpieczeniami informacji.
Kompilowane na platformie Azure
Hostujemy usługę Azure DevOps w całości w centrach danych platformy Azure. Usługa Azure DevOps korzysta z wielu podstawowych usług platformy Azure, w tym obliczeń, magazynu, sieci, usługi Azure SQL, zarządzania tożsamościami i dostępem oraz usługi Azure Service Bus.
Azure DevOps używa usługi Azure Storage jako podstawowego repozytorium metadanych usługi i danych klientów. W zależności od typu danych oraz wymagań dotyczących magazynu i pobierania usługa Azure DevOps używa usługi Azure Blob Storage i usługi Azure SQL Database Storage.
Aby ułatwić zrozumienie podejścia usługi Azure DevOps Services do ochrony danych, oto pewne doświadczenie w usługach magazynu:
Usługa Azure Blob Storage przechowuje duże fragmenty danych bez struktury. Wszystkie projekty korzystają z tej usługi. Dane obejmują potencjalnie poufne lub prywatne informacje, takie jak zawartość plików źródłowych i załączników w zakresie elementów roboczych. W przypadku większości projektów większość używanych magazynów to ten typ magazynu obiektów blob bez struktury.
Usługa Azure SQL Database przechowuje ustrukturyzowane i transakcyjne aspekty organizacji, w tym metadane projektu, historię kontroli źródła wersji i szczegóły elementów roboczych. Magazyn bazy danych zapewnia szybki dostęp do ważnych elementów projektu. Udostępnia indeksy do magazynu obiektów blob w celu wyszukiwania plików i załączników.
Administratorzy mogą zarządzać dostępem do zasobów, udzielając lub ograniczając uprawnienia do tożsamości użytkowników lub grup. Usługa Azure DevOps używa federacyjnego uwierzytelniania tożsamości użytkowników za pośrednictwem identyfikatora Microsoft Entra ID i kont Microsoft.
Podczas uwierzytelniania użytkownik jest kierowany do dostawcy uwierzytelniania, gdzie podaje swoje poświadczenia. Po zweryfikowaniu poświadczeń użytkownika przez dostawcę uwierzytelniania usługa Azure DevOps wystawia użytkownikowi plik cookie uwierzytelniania. Ten plik cookie umożliwia użytkownikowi pozostanie uwierzytelniony w usłudze Azure DevOps.
W ten sposób informacje o poświadczeniach użytkownika nigdy nie są udostępniane bezpośrednio usłudze Azure DevOps. W przypadku każdego zasobu usługi Azure DevOps, do którego użytkownik próbuje uzyskać dostęp, weryfikacja uprawnień jest oparta na jawnych uprawnieniach użytkownika i uprawnieniach dziedziczonego przez użytkownika za pośrednictwem członkostwa w grupie.
Administratorzy mogą używać kontroli dostępu, aby chronić dostęp do organizacji, kolekcji projektów, projektów zespołowych i danych i funkcji o zakresie zespołu. Administratorzy mogą również używać kontroli dostępu dla określonych zasobów, takich jak foldery do kontroli wersji i ścieżek obszaru dla elementów roboczych.
Dostępność danych
Usługa Azure DevOps używa wielu funkcji usługi Azure Storage, aby zapewnić dostępność danych w przypadku awarii sprzętu, przerw w działaniu usługi lub awarii regionalnej. Ponadto zespół usługi Azure DevOps postępuje zgodnie z procedurami, aby chronić dane przed przypadkowym lub złośliwym usunięciem.
Nadmiarowość danych
Aby ułatwić ochronę danych podczas awarii sprzętu lub usługi, usługa Azure Storage replikuje dane klienta między dwoma regionami w tej samej lokalizacji geograficznej. Na przykład usługa Azure Storage może replikować geograficznie dane między Europą Północną a Zachodnią lub między Stany Zjednoczone Północnej i Południowej.
W przypadku usługi Azure Blob Storage dane klientów są replikowane trzy razy w jednym regionie. Dane klienta są replikowane asynchronicznie do drugiego regionu w tej samej lokalizacji geograficznej. W związku z tym platforma Azure zawsze utrzymuje odpowiednik sześciu kopii danych.
Posiadanie wielu kopii umożliwia przełączenie w tryb failover do oddzielnego regionu, jeśli wystąpi awaria lub awaria, a także lokalna nadmiarowość w przypadku awarii sprzętu w regionie. W przypadku magazynu usługi Azure SQL Database codzienne kopie zapasowe są przechowywane poza siedzibą firmy, jeśli wystąpi awaria regionalna.
Dotyczy nadmiarowości danych i trybu failover:
- Istnieje nieodłączna różnica mierzona w minutach, gdy firma Microsoft replikuje dane między regionem podstawowym i pomocniczym.
- Przejście w tryb failover do regionu pomocniczego to decyzja, którą firma Microsoft musi podjąć centralnie, ponieważ ma wpływ na wszystkich klientów w określonej jednostce skalowania. Z wyjątkiem skrajnych sytuacji firma Microsoft decyduje się uniknąć przełączania w tryb failover, aby dane klientów nie zostaną utracone.
- Usługa Azure DevOps oferuje umowę dotyczącą poziomu usług (SLA) w wysokości 99,9 procent czasu pracy. Usługa Azure DevOps zwraca część miesięcznych opłat, jeśli przegapi tę umowę SLA w określonym miesiącu.
- Ponieważ w Brazylii istnieje tylko jeden region, dane klientów w Brazylii są replikowane do regionu Południowo-środkowe stany USA na potrzeby odzyskiwania po awarii.
Zdarzają się błędy
Aby zapewnić ochronę przed przypadkową utratą danych, firma Microsoft stosuje kopie zapasowe do punktu w czasie dla obu obiektów blob przechowywanych w usłudze Azure Blob Storage i bazach danych w usłudze Azure SQL Database. Każde konto magazynu przechowuje oddzielną kopię wszystkich obiektów blob, a zmiany są dołączane do istniejących danych. Te kopie zapasowe są niezmienne, eliminując konieczność ponownego zapisywania istniejącego magazynu podczas wykonywania procedur tworzenia kopii zapasowych.
Usługa Azure SQL Database obejmuje standardowe funkcje tworzenia kopii zapasowych używane przez usługę Azure DevOps. Dane są przechowywane przez 28 dni, a te kopie zapasowe są również replikowane w sparowanym regionie w celu ułatwienia odzyskiwania podczas regionalnej awarii.
Po usunięciu można odzyskać usunięte organizacje lub projekty w 28-dniowym przed usunięciem. Jednak po upływie tego okresu te jednostki są trwale usuwane i nie można ich przywrócić. Chociaż te kopie zapasowe stanowią kluczowy składnik odzyskiwania po awarii, ważne jest, aby klienci ćwiczyli odpowiednie strategie zarządzania danymi i tworzenia kopii zapasowych w celu zapewnienia kompleksowej ochrony danych.
Ważne
- Tutaj przypadkowe usunięcie odnosi się do scenariuszy, które pojawiają się w wyniku zdarzenia w naszych usługach. Nie obejmuje przypadkowego usunięcia zasobów przez klientów (na przykład repozytoriów, elementów roboczych, załączników lub artefaktów).
- Nie obsługujemy przywracania zasobów, które klienci przypadkowo usuwają. Te kopie zapasowe są przeznaczone tylko dla ciągłości działania i ułatwiają odzyskiwanie po awarii lub awarii.
- W rzadkich przypadkach proces usuwania może potrwać do 70 dni z powodu ponownych prób zaplecza i konieczności usunięcia danych z wielu źródeł.
Praktyka jest krytyczna
Posiadanie wielu kopii zapasowych danych jest dobre, ale bez praktyki przywracanie może być nieprzewidywalne. Ludzie mówią, że "kopie zapasowe nigdy nie kończą się niepowodzeniem; wykonać operacje przywracania". Chociaż instrukcja jest technicznie niepoprawna, tonacja jest prawidłowa.
Firma Microsoft regularnie praktykuje przywracanie zestawów danych z kopii zapasowej. Regularnie testujemy magazyn geograficznie nadmiarowy z platformy Azure. Istnieje wiele kombinacji scenariuszy awarii i uszkodzenia danych. Stale planujemy i przeprowadzamy nowe testy dla tych scenariuszy.
Dostępność usługi
Usługa Azure DevOps oferuje ochronę przed rozproszoną odmową usługi (DDoS) i odpowiedzi na witrynę na żywo, aby zapewnić, że masz dostęp do organizacji i skojarzonych zasobów.
Ochrona przed atakami DDoS
W niektórych przypadkach złośliwy atak DDoS może mieć wpływ na dostępność usługi. Platforma Azure ma system obrony DDoS, który pomaga zapobiegać atakom na naszą usługę. Używa standardowych technik wykrywania i ograniczania ryzyka, takich jak pliki cookie SYN, ograniczanie szybkości i limity połączeń. System jest przeznaczony do wytrzymania ataków nie tylko z zewnątrz, ale także z poziomu platformy Azure.
W przypadku ataków specyficznych dla aplikacji, które mogą przeniknąć do systemów obrony platformy Azure, usługa Azure DevOps ustanawia limity przydziału na poziomie aplikacji i na poziomie organizacji oraz ograniczanie przepustowości. Ta praktyka pomaga zapobiec nadmiernemu wykorzystaniu kluczowych zasobów usługi podczas ataku lub przypadkowego nieprawidłowego użycia zasobów.
Odpowiedź witryny na żywo
W rzadkich okolicznościach może być wymagana odpowiedź na żywo witryny na problem z dostępnością usługi. Mamy zespół operacyjny, który jest stale dostępny, aby szybko zidentyfikować problem i zaangażować niezbędne zasoby zespołu deweloperskiego.
Zasoby zespołu deweloperów następnie rozwiążą problem. Mają również na celu zaktualizowanie strony stanu usługi w ciągu kilku minut od wykrycia problemu, który ma wpływ na usługę. Po rozwiązaniu problemu przez zasoby zespołu deweloperów identyfikują główną przyczynę i śledzą niezbędne zmiany, aby zapobiec podobnym problemom w przyszłości.
Procesy usługi Azure DevOps na potrzeby zarządzania lokacjami na żywo koncentrują się na środowisku i kondycji usługi. Te procesy minimalizują czas wykrywania, reagowania i rozwiązywania problemów. Wszystkie dyscypliny inżynieryjne są zaangażowane i odpowiedzialne, więc ciągłe ulepszenia rozwijają się poza bezpośrednim doświadczeniem. Monitorowanie, diagnostyka, odporność i procesy zapewniania jakości, a następnie poprawianie się w miarę upływu czasu.
Zarządzanie witrynami na żywo w usłudze Azure DevOps ma trzy odrębne ścieżki: dane telemetryczne, zarządzanie zdarzeniami i przegląd witryny na żywo. Oto, co obejmują te ścieżki:
Zespół operacyjny monitoruje również metryki dostępności dla poszczególnych organizacji. Te metryki zapewniają wgląd w konkretne warunki, które mogą mieć wpływ tylko na niektórych z naszych klientów. Badania dotyczące tych danych mogą często skutkować ukierunkowanymi ulepszeniami w celu rozwiązania problemów specyficznych dla klienta. W niektórych przypadkach firma Microsoft może nawet skontaktować się z Tobą bezpośrednio, aby zrozumieć twoje doświadczenie i współpracować z Tobą w celu ulepszenia usługi.
Firma Microsoft publikuje umowę SLA i zapewnia gwarancję finansową w celu zapewnienia, że co miesiąc spełniamy tę umowę. Aby uzyskać więcej informacji, zobacz Umowa SLA dla usługi Azure DevOps.
Czasami zespoły partnerskie lub zależności mają zdarzenia wpływające na usługę Azure DevOps. Wszystkie zespoły partnerskie stosują podobne podejścia do identyfikowania, rozwiązywania i uczenia się z tych awarii usług.
Zabezpieczenia usługi
Bezpieczeństwo usługi wymaga stałej czujności, od odpowiednich technik projektowania i kodowania po czynniki operacyjne. Firma Microsoft aktywnie inwestuje w zapobieganie lukom bezpieczeństwa i wykrywaniu naruszeń. Jeśli wystąpi naruszenie, firma Microsoft korzysta z planów reagowania na zabezpieczenia w celu zminimalizowania wycieku, utraty lub uszkodzenia danych. Aby uzyskać więcej informacji, zobacz Informacje o zabezpieczeniach, uwierzytelnianiu i autoryzacji.
Zabezpieczenia według projektu
Usługa Azure DevOps została zaprojektowana pod kątem bezpieczeństwa. Usługa Azure DevOps korzysta z cyklu projektowania zabezpieczeń firmy Microsoft w ramach procesu programowania. Program Microsoft Operational Security Assurance prowadzi procedury operacji w chmurze w usłudze Azure DevOps.
Zespół usługi Azure DevOps ma roczne wymagania szkoleniowe dla wszystkich inżynierów i personelu operacyjnego. Zespół sponsoruje również nieformalne spotkania organizowane przez inżynierów firmy Microsoft. Gdy zespół rozwiąże problem, który pojawia się na spotkaniu, dzieli się doświadczeniami wyciągniętymi z innych zespołów.
Następujące metodologie określają wymagania szkoleniowe:
- Modelowanie zagrożeń podczas projektowania usługi
- Przestrzeganie najlepszych rozwiązań dotyczących projektowania i kodu
- Weryfikowanie zabezpieczeń przy użyciu standardowych narzędzi i testowania
- Ograniczanie dostępu do danych operacyjnych i danych klientów
- Gating rollout of new features through a sztywny proces zatwierdzania
Usługa w chmurze jest bezpieczna tylko jako platforma hosta. Usługa Azure DevOps używa usługi PaaS dla dużej części swojej infrastruktury. Usługa PaaS automatycznie udostępnia regularne aktualizacje znanych luk w zabezpieczeniach.
Maszyny wirtualne hostowane na platformie Azure używają infrastruktury jako usługi (IaaS), takiej jak hostowana usługa kompilacji. Takie obrazy otrzymują regularne aktualizacje, aby uwzględnić najnowsze poprawki zabezpieczeń dostępne w usłudze Windows Update. Ten sam zestaw aktualizacji dotyczy maszyn lokalnych, w tym maszyn używanych do wdrażania, monitorowania i raportowania.
Zespół usługi Azure DevOps przeprowadza regularne, ukierunkowane na zabezpieczenia testy penetracyjne usługi Azure DevOps. Testy penetracyjne próbują wykorzystać na żywo usługi produkcyjne i infrastrukturę usługi Azure DevOps przy użyciu tych samych technik i mechanizmów, których używają złośliwi atakujący. Celem jest zidentyfikowanie rzeczywistych luk w zabezpieczeniach, konfiguracji, błędów lub innych luk w zabezpieczeniach w kontrolowanym procesie.
Zespół przegląda wyniki tych testów, aby zidentyfikować inne obszary poprawy i zwiększyć jakość systemów zapobiegawczych i szkoleń. Możesz przejrzeć wyniki ostatnich testów penetracyjnych usługi Azure DevOps w portalu zaufania usług firmy Microsoft.
Zabezpieczenia poświadczeń
Firma Microsoft dokłada wszelkich starań, aby Twoje projekty były bezpieczne i bezpieczne bez wyjątku. W usłudze Azure DevOps projekty korzystają z wielu warstw technologii zabezpieczeń i ładu, praktyk operacyjnych i zasad zgodności. Wymuszamy prywatność i integralność danych zarówno magazynowanych, jak i przesyłanych. Ponadto stosujemy się do poniższych praktyk w odniesieniu do poświadczeń lub wpisów tajnych przechowywanych przez usługę Azure DevOps. Aby dowiedzieć się więcej na temat wybierania odpowiedniego mechanizmu uwierzytelniania, zobacz Wskazówki dotyczące uwierzytelniania.
Ważne
Usługa Azure DevOps nie obsługuje uwierzytelniania poświadczeń alternatywnych. Jeśli nadal używasz alternatywnych poświadczeń, zdecydowanie zachęcamy do przełączenia się na bardziej bezpieczną metodę uwierzytelniania.
Osobiste tokeny dostępu (PATs)
- Przechowujemy skrót patu.
- Nieprzetworzone elementy PAT generują w pamięci po stronie serwera. 32 bajty losowo generowane za pośrednictwem elementu RNGCryptoServiceProvider i są udostępniane obiektowi wywołującym jako ciąg zakodowany w formacie base-32. Ta wartość NIE jest przechowywana.
- Skrót PAT generuje w pamięci po stronie serwera jako HMACSHA256Hash nieprzetworzonego pat przy użyciu 64-bajtowego klucza podpisywania symetrycznego przechowywanego w naszym magazynie kluczy.
- Skrót jest przechowywany w naszej bazie danych.
Klucze protokołu Secure Shell (SSH)
- Przechowujemy skrót otaczającego identyfikatora organizacji i klucza publicznego SSH.
- Nieprzetworzone klucze publiczne są dostarczane bezpośrednio przez obiekt wywołujący za pośrednictwem protokołu SSL.
- Skrót SSH generuje w pamięci po stronie serwera jako HMACSHA256Hash identyfikatora organizacji i nieprzetworzonego klucza publicznego przy użyciu 64-bajtowego klucza podpisywania symetrycznego przechowywanego w naszym magazynie kluczy.
- Skrót jest przechowywany w naszej bazie danych.
Poświadczenia protokołu OAuth (JWTs)
- Problem z poświadczeniami protokołu OAuth jako w pełni opisujący tokeny internetowe JSON (JWTs) i nie są przechowywane w naszej usłudze.
- Oświadczenia w JWTs wystawione i przedstawione naszej usłudze są weryfikowane przy użyciu certyfikatu przechowywanego w naszym magazynie kluczy.
Raportowanie błędów zabezpieczeń
Jeśli uważasz, że testy penetracyjne wykazały potencjalną wadę zabezpieczeń związaną z usługą Azure DevOps, zgłoś ją firmie Microsoft w ciągu 24 godzin. Aby uzyskać więcej informacji, zobacz stronę internetową firmy Microsoft dotyczącą zgłaszania luk w zabezpieczeniach komputera.
Ważne
Chociaż nie musisz powiadamiać firmy Microsoft o działaniach dotyczących testów penetracyjnych, musisz przestrzegać reguł testowania penetracyjnego firmy Microsoft.
Program Bounty
Usługa Azure DevOps uczestniczy w programie Microsoft Bug Bounty. Ten program nagradza badaczy zabezpieczeń, którzy zgłaszają nam problemy, i zachęca więcej osób do zapewnienia bezpieczeństwa usługi Azure DevOps. Aby uzyskać więcej informacji, zobacz Microsoft Azure DevOps Bounty Program.
Ograniczanie dostępu
Firma Microsoft utrzymuje ścisłą kontrolę nad tym, kto uzyskuje dostęp do naszego środowiska produkcyjnego i danych klientów. Udzielamy dostępu na poziomie wymaganego najniższych uprawnień i tylko po weryfikacji uzasadnienia użytkownika. Jeśli członek zespołu potrzebuje dostępu, aby rozwiązać pilny problem lub wdrożyć zmianę konfiguracji, musi ubiegać się o dostęp just in time do usługi produkcyjnej. Dostęp zostanie odwołany natychmiast po rozwiązaniu problemu.
Śledzimy i monitorujemy żądania dostępu i zatwierdzenia w osobnym systemie. Cały dostęp do systemu jest skorelowany z tymi zatwierdzeniami. Jeśli wykryjemy niezatwierdzony dostęp, powiadomimy zespół operacyjny o zbadaniu.
Używamy uwierzytelniania dwuskładnikowego dla całego dostępu do systemu zdalnego. Jeśli nazwa użytkownika i hasło dla jednego z naszych deweloperów lub personelu operacyjnego zostaną skradzione, dane pozostają chronione. Więcej kontroli uwierzytelniania za pośrednictwem karty inteligentnej lub połączenia telefonicznego do wstępnie zatwierdzonego numeru musi nastąpić, zanim zezwolimy na zdalny dostęp do usługi.
Aby zarządzać usługą i obsługiwać nią, firma Microsoft używa wpisów tajnych, takich jak hasła RDP, certyfikaty SSL i klucze szyfrowania. Te wpisy tajne są zarządzane, przechowywane i przesyłane bezpiecznie za pośrednictwem witryny Azure Portal. Każdy dostęp do tych wpisów tajnych wymaga określonych uprawnień, które są rejestrowane i rejestrowane bezpiecznie. Wszystkie wpisy tajne są obracane w regularnych okresach i możemy je obracać na żądanie, jeśli istnieje zdarzenie zabezpieczeń.
Zespół operacyjny usługi Azure DevOps używa stacji roboczych administratora ze wzmocnionymi zabezpieczeniami do zarządzania usługą. Te maszyny uruchamiają minimalną liczbę aplikacji i działają w logicznie segmentowym środowisku.
Członkowie zespołu ds. operacji muszą podać określone poświadczenia z uwierzytelnianiem dwuskładnikowym w celu uzyskania dostępu do stacji roboczych. Cały dostęp jest monitorowany i bezpiecznie rejestrowany. Aby odizolować usługę przed naruszeniami zewnętrznymi, nie zezwalamy na aplikacje, takie jak Outlook i Office, ponieważ często są one celem wyłudzania informacji i innych typów ataków.
Ochrona i reagowanie na nieautoryzowane włamanie
Szyfrujemy dane za pośrednictwem protokołu HTTPS i protokołu SSL, aby zapewnić, że nie są przechwytywane ani modyfikowane podczas przesyłania między tobą i usługą Azure DevOps. Dane przechowywane w Twoim imieniu w usłudze Azure DevOps są szyfrowane w następujący sposób:
Dane przechowywane w bazach danych Azure SQL Database są szyfrowane za pośrednictwem przezroczystego szyfrowania danych. Ta funkcja pomaga chronić przed złośliwym działaniem, wykonując szyfrowanie w czasie rzeczywistym bazy danych, skojarzonych kopii zapasowych i plików dziennika transakcji magazynowanych.
Połączenia usługi Azure Blob Storage są szyfrowane w celu ochrony przesyłanych danych. W przypadku danych magazynowanych w usłudze Azure Blob Storage usługa Azure DevOps używa szyfrowania po stronie usługi.
Zespół usługi Azure DevOps używa infrastruktury platformy Azure do rejestrowania i monitorowania kluczowych aspektów usługi. Rejestrowanie i monitorowanie pomaga zagwarantować, że działania w ramach usługi są uzasadnione i pomagają wykrywać naruszenia lub próby naruszenia.
Wszystkie działania związane z wdrażaniem i administratorem są bezpiecznie rejestrowane, podobnie jak dostęp operatora do magazynu produkcyjnego. Informacje dziennika są automatycznie analizowane, a wszelkie potencjalnie złośliwe lub nieautoryzowane zachowanie zgłasza alerty w czasie rzeczywistym.
Gdy zespół usługi Azure DevOps zidentyfikuje możliwe włamanie lub lukę w zabezpieczeniach o wysokim priorytcie, ma jasny plan reagowania. Ten plan zawiera opis odpowiedzialnych stron, wymaganych kroków dotyczących zabezpieczania danych klientów oraz instrukcji dotyczących angażowania się w kontakt z ekspertami ds. zabezpieczeń w firmie Microsoft. Zespół powiadamia również wszystkich właścicieli organizacji, czy dane zostały ujawnione lub uszkodzone, aby mogli podjąć odpowiednie kroki w celu rozwiązania tej sytuacji.
Aby pomóc w walce z pojawiającymi się zagrożeniami, usługa Azure DevOps stosuje strategię zakładania naruszenia . Wysoce wyspecjalizowany zespół ekspertów ds. zabezpieczeń w firmie Microsoft przyjmuje rolę zaawansowanych przeciwników. Ten zespół testuje wykrywanie i reagowanie na naruszenia, aby dokładnie mierzyć gotowość i wpływ rzeczywistych ataków. Ta strategia wzmacnia wykrywanie zagrożeń, reagowanie i ochronę usługi. Umożliwia również zespołowi weryfikowanie i poprawianie skuteczności całego programu zabezpieczeń.
Ochrona przed atakami wymuszającym okup
Usługa Azure DevOps używa kontrolek platformy Azure, aby zapobiegać atakom wymuszającym okup, wykrywać je i reagować na nie. Aby uzyskać więcej informacji na temat sposobu, w jaki platforma Azure pomaga chronić klientów przed atakami wymuszającym okup, zobacz Ochrona przed oprogramowaniem wymuszającym okup na platformie Azure.
Prywatność danych
Należy mieć pewność, że odpowiednio obsługujemy Twoje dane i do uzasadnionych zastosowań. Część tego zapewnienia obejmuje dokładne ograniczenie użycia.
Ogólne rozporządzenie o ochronie danych
Ogólne rozporządzenie o ochronie danych (RODO) jest największą zmianą przepisów dotyczących ochrony danych w Europie od czasu wprowadzenia do 1995 r. dyrektywy o ochronie danych Unii Europejskiej (UE) 95/46/WE. Aby uzyskać więcej informacji na temat RODO, zobacz stronę przeglądu w Centrum zaufania firmy Microsoft.
Rezydencja i niezależność danych
Usługa Azure DevOps jest dostępna w następujących ośmiu lokalizacjach geograficznych na całym świecie: Stany Zjednoczone, Kanada, Europa, Wielka Brytania, Indie, Australia, Azja i Pacyfik oraz Brazylia. Domyślnie twoja organizacja jest przypisana do najbliższej lokalizacji. Możesz jednak wybrać inną lokalizację podczas tworzenia organizacji. Jeśli później zmienisz zdanie, możesz przeprowadzić migrację organizacji do innej lokalizacji, udzielając pomocy technicznej firmy Microsoft.
Usługa Azure DevOps nie przenosi ani nie replikuje danych klientów poza wybraną lokalizacją. Zamiast tego dane są replikowane geograficznie do drugiego regionu w tej samej lokalizacji. Jedynym wyjątkiem jest Brazylia, która replikuje dane do regionu Południowo-środkowe stany USA na potrzeby odzyskiwania po awarii.
Uwaga
W przypadku kompilacji i wydań uruchamianych na agentach systemu macOS udostępnianych przez firmę Microsoft dane są przesyłane do centrum danych Usługi GitHub w Stany Zjednoczone.
Aby uzyskać więcej informacji, zobacz Lokalizacje danych dla usługi Azure DevOps.
Dostęp organów ścigania
W niektórych przypadkach osoby trzecie, takie jak organy ścigania, mogą podejść do firmy Microsoft w celu uzyskania dostępu do danych klientów przechowywanych w usłudze Azure DevOps. Próbujemy przekierować żądania do właściciela organizacji w celu rozwiązania problemu. Gdy nakaz sądowy zmusza firmę Microsoft do ujawnienia danych klienta osobie trzeciej, firma Microsoft podejmuje rozsądny wysiłek, aby powiadomić właściciela organizacji z wyprzedzeniem, chyba że firma Microsoft będzie prawnie zabroniona.
Niektórzy klienci wymagają przechowywania danych w określonej lokalizacji geograficznej, aby zapewnić konkretną jurysdykcję prawną dla wszelkich działań organów ścigania. Wszystkie dane klienta, takie jak kod źródłowy, elementy robocze, wyniki testów i dublowania geograficznie nadmiarowe oraz kopie zapasowe poza siedzibą firmy, są przechowywane w jednej z wcześniej wymienionych lokalizacji.
Dostęp firmy Microsoft
Od czasu do czasu pracownicy firmy Microsoft muszą uzyskać dostęp do danych klientów przechowywanych w usłudze Azure DevOps. Jako środek ostrożności wszyscy pracownicy, którzy mają (lub kiedykolwiek mieć) dostęp do danych klientów, muszą przejść kontrolę w tle obejmującą wcześniejsze wyroki skazujące za zatrudnienie i karne. Zezwalamy na dostęp do systemów produkcyjnych tylko wtedy, gdy występuje zdarzenie na żywo lub inne zatwierdzone działania konserwacyjne, które są rejestrowane i monitorowane.
Ponieważ nie wszystkie dane w naszym systemie są traktowane w ten sam sposób, klasyfikujemy dane na następujące typy:
- Dane klienta: co przekazujesz do usługi Azure DevOps.
- Dane organizacji: informacje przesyłane podczas tworzenia konta lub administrowania organizacją.
- Dane firmy Microsoft: informacje wymagane do lub zebrane za pośrednictwem działania usługi.
Na podstawie klasyfikacji kontrolujemy scenariusze użycia, wymagania dotyczące lokalizacji geograficznej, ograniczenia dostępu i wymagania dotyczące przechowywania.
Korzystanie z promocji firmy Microsoft
Firma Microsoft od czasu do czasu chce skontaktować się z klientami, aby poinformować ich o dodatkowych funkcjach i usługach, które mogą być przydatne. Ponieważ nie wszyscy klienci chcą się skontaktować z tymi ofertami, możesz wyrazić zgodę i zrezygnować z marketingowej komunikacji e-mail.
Firma Microsoft nigdy nie używa danych klientów do określania konkretnych ofert dla określonych użytkowników lub organizacji. Zamiast tego używamy danych organizacji i agregujemy statystyki użycia na poziomie organizacji, aby określić grupy, które powinny otrzymywać określone oferty.
Budowanie pewności
Możesz mieć pewność, że firma Microsoft podejmuje inne działania w imieniu usługi Azure DevOps. Działania te obejmują wewnętrzne zasady wdrażania w firmie Microsoft, poziom przejrzystości w stanie naszej usługi oraz postęp w kierunku otrzymania certyfikacji naszych systemów na potrzeby zarządzania zabezpieczeniami informacji.
Wdrażanie wewnętrzne
Zespoły firmy Microsoft wdrażają wewnętrznie usługę Azure DevOps. Zespół usługi Azure DevOps przeniósł się do organizacji w 2014 roku i korzysta z niej w szerokim zakresie. Ustaliliśmy wytyczne umożliwiające włączenie planów wdrażania dla innych zespołów.
Duże zespoły przechodzą stopniowo niż mniejsze, ze względu na inwestycje w istniejące systemy DevOps. W przypadku zespołów, które szybko się poruszają, ustaliliśmy podejście do klasyfikacji projektów. Ocenia tolerancję ryzyka na podstawie cech projektu, aby określić, czy projekt jest odpowiedni dla usługi Azure DevOps. W przypadku większych zespołów wdrożenie zwykle odbywa się w fazach, przy użyciu większego planowania.
Więcej wymagań dotyczących projektów wewnętrznych obejmuje kojarzenie organizacji z identyfikatorem Microsoft Entra ID w celu zapewnienia prawidłowego cyklu życia tożsamości użytkownika i złożoności hasła. Projekty, które są bardziej wrażliwe, również wymagają uwierzytelniania dwuskładnikowego.
Certyfikaty zgodności
Możesz być zainteresowany zrozumieniem oceny naszych procedur dotyczących zabezpieczeń danych przez inną firmę. Usługa Azure DevOps uzyskała następujące certyfikaty:
- ISO 27001:2013
- ISO 27018:2019
- ISO 26262:2023
- Health Insurance Portability and Accountability Act (HIPAA)
- Umowa biznesowa (BAA)
- EU Model Clauses
- Kontrolki systemowe i organizacyjne (SOC) 1 typ 2
- SOC 2 Typ 2
- Niemcy C5
- Australia — program IRAP
- ENS-Hiszpania
Inspekcja SOC dla usługi Azure DevOps obejmuje mechanizmy kontroli zabezpieczeń, dostępności, integralności przetwarzania i poufności danych. Raporty SOC dla usługi Azure DevOps są dostępne za pośrednictwem portalu zaufania usług firmy Microsoft.
Kwestionariusz inicjatywy oceny konsensusu (CAIQ) pomaga organizacjom ocenić i ocenić praktyki w zakresie zabezpieczeń i możliwości dostawców usług w chmurze. Zgodnie z naszym zobowiązaniem do bezpieczeństwa i przejrzystości niedawno ukończyliśmy ocenę CAIQ dla usługi Azure DevOps. Zachęcamy do przejrzenia pełnego raportu w portalu zaufania usług firmy Microsoft.
Kroki, które można wykonać
Właściwa ochrona danych wymaga aktywnego zaangażowania od Ciebie, administratorów i użytkowników. Dane projektu przechowywane w usłudze Azure DevOps są bezpieczne tylko w przypadku punktów dostępu użytkowników. Dopasuj poziom dokładności uprawnień i stopień szczegółowości dla tych organizacji z poziomem poufności projektu.
Klasyfikowanie danych
Pierwszym krokiem jest sklasyfikowanie danych. Klasyfikowanie danych na podstawie poufności i horyzontu ryzyka wraz z uszkodzeniem, które mogą wystąpić w przypadku naruszenia zabezpieczeń. Wiele przedsiębiorstw ma istniejące metody klasyfikacji, których mogą używać ponownie podczas przenoszenia projektów do usługi Azure DevOps. Aby uzyskać więcej informacji, możesz pobrać klasyfikację danych pod kątem gotowości do chmury z witryny Microsoft Trustworthy Computing.
Wdrażanie identyfikatora entra firmy Microsoft
Użyj identyfikatora Entra firmy Microsoft, aby zarządzać dostępem organizacji do usługi Azure DevOps. Identyfikator Entra firmy Microsoft umożliwia zwiększenie bezpieczeństwa poświadczeń użytkowników.
Microsoft Entra ID umożliwia działowi IT zarządzanie zasadami dostępu użytkowników, złożonością haseł, odświeżaniem haseł i wygaśnięciem po opuszczeniu organizacji przez użytkowników. Za pomocą federacji usługi Active Directory można bezpośrednio połączyć identyfikator Firmy Microsoft z centralnym katalogiem organizacji, dzięki czemu masz tylko jedną lokalizację do zarządzania tymi szczegółami dla przedsiębiorstwa.
W poniższej tabeli porównaliśmy cechy konta Microsoft i usługi Microsoft Entra względem dostępu do usługi Azure DevOps:
| Właściwości | Konto Microsoft | Microsoft Entra ID |
|---|---|---|
| Twórca tożsamości | User | Organizacja |
| Pojedyncza nazwa użytkownika i hasło dla wszystkich zasobów roboczych | Nie. | Tak |
| Kontrola okresu istnienia i złożoności hasła | User | Organizacja |
| Limity członkostwa w usłudze Azure DevOps | Dowolne konto Microsoft | Katalog organizacji |
| Tożsamość z możliwością śledzenia | Nie. | Tak |
| Własność organizacji i adresu IP | Niejasny | Organizacja |
| Rejestracja uwierzytelniania dwuskładnikowego | User | Organizacja |
| Dostęp warunkowy oparty na urządzeniach | Nie. | Organizacja |
Dowiedz się więcej na temat konfigurowania tej pomocy technicznej dla organizacji.
Wymaganie uwierzytelniania dwuskładnikowego
Możesz ograniczyć dostęp do organizacji, wymagając więcej niż jednego czynnika do zalogowania się. Możesz wymagać wielu czynników przy użyciu identyfikatora Entra firmy Microsoft. Na przykład możesz wymagać uwierzytelniania za pomocą telefonu, oprócz nazwy użytkownika i hasła, dla wszystkich żądań uwierzytelniania.
Korzystanie z funkcji BitLocker
W przypadku projektów poufnych można użyć funkcji BitLocker na komputerze przenośnym lub stacjonarnym z systemem Windows. Funkcja BitLocker szyfruje cały dysk, na którym znajdują się systemy Windows i dane. Gdy funkcja BitLocker jest włączona, automatycznie szyfruje wszystkie pliki zapisane na tym dysku. Jeśli komputer wchodzi w złe ręce, funkcja BitLocker uniemożliwia nieautoryzowany dostęp do lokalnych kopii danych z projektów.
Ograniczanie użycia poświadczeń uwierzytelniania alternatywnego
Domyślny mechanizm uwierzytelniania dla narzędzi związanych z usługą Git to uwierzytelnianie alternatywne (czasami nazywane uwierzytelnianiem podstawowym). Ten mechanizm umożliwia użytkownikowi skonfigurowanie alternatywnej nazwy użytkownika i hasła do użycia podczas operacji wiersza polecenia usługi Git. Użytkownik może użyć tej kombinacji nazwy użytkownika/hasła, aby uzyskać dostęp do innych danych, dla których ten użytkownik ma uprawnienia. Z tego względu alternatywne poświadczenia uwierzytelniania są mniej bezpieczne niż domyślne uwierzytelnianie federacyjne.
Nadal możesz dokonać wyborów w celu zwiększenia bezpieczeństwa. Cała komunikacja jest wysyłana za pośrednictwem protokołu HTTPS i istnieją wymagania dotyczące złożoności hasła. Twoja organizacja powinna nadal oceniać, czy potrzebuje więcej zasad, aby spełnić wymagania dotyczące zabezpieczeń projektów.
Jeśli zdecydujesz, że nie spełnia wymagań dotyczących zabezpieczeń organizacji, możesz wyłączyć poświadczenia uwierzytelniania alternatywnego. Aby uzyskać więcej informacji, zobacz Zmienianie zasad zabezpieczeń i połączeń aplikacji dla organizacji.
Bezpieczny dostęp do organizacji
Administratorzy mogą użyć identyfikatora Entra firmy Microsoft do kontrolowania dostępu do zasobów i aplikacji platformy Azure, takich jak Azure DevOps. Po zastosowaniu kontroli dostępu warunkowego identyfikator Entra firmy Microsoft sprawdza określone warunki ustawione dla użytkownika w celu uzyskania dostępu do aplikacji. Po spełnieniu wymagań dostępu użytkownik jest uwierzytelniany i może uzyskać dostęp do aplikacji.
Usługa Azure DevOps obsługuje wymuszanie niektórych typów zasad dostępu warunkowego (na przykład ogrodzenia adresów IP) dla niestandardowych mechanizmów uwierzytelniania usługi Azure DevOps. Te mechanizmy obejmują osobiste tokeny dostępu, alternatywne uwierzytelnianie, protokół OAuth i klucze protokołu Secure Shell (SSH). Jeśli użytkownicy uzyskują dostęp do usługi Azure DevOps za pośrednictwem klienta innej firmy, obowiązują tylko zasady oparte na protokole IPv4.