Bezpieczeństwo

Tunele deweloperskie to usługa tunelowania deweloperów skoncentrowana na zabezpieczeniach. W tym artykule dowiesz się, jak są zabezpieczone tunele deweloperskie.

Przegląd

Domyślnie hostowanie i nawiązywanie połączenia z tunelem wymaga uwierzytelniania za pomocą tego samego konta Microsoft, Microsoft Entra ID lub GitHub, które utworzyło tunel. Tunelowanie wymaga nawiązania połączeń wychodzących z usługą hostowaną na platformie Azure. Do korzystania z usługi nie są wymagane żadne połączenia przychodzące.

Domeny

Dostęp do tuneli deweloperskich można kontrolować, zezwalając na dostęp wychodzący do następujących domen lub odmawiając dostępu wychodzącego do następujących domen:

• Uwierzytelnianie

  • github.com
  • login.microsoftonline.com

• Tunele deweloperskie

  • global.rel.tunnels.api.visualstudio.com
  • [clusterId].rel.tunnels.api.visualstudio.com
  • [clusterId]-data.rel.tunnels.api.visualstudio.com
  • *.[clusterId].devtunnels.ms
  • *.devtunnels.ms

Lista bieżących [clusterId] wartości jest dostępna pod adresem https://global.rel.tunnels.api.visualstudio.com/api/v1/clusters.

Przekazywanie do sieci Web

Dostęp do portów tunelu przy użyciu protokołów HTTP(S)/WS(S) można uzyskać bezpośrednio za pośrednictwem podanego adresu URL przekazywania internetowego (na przykład: https://tunnelid-3000.devtunnels.ms).

• Niezabezpieczone połączenia klienckie są zawsze automatycznie uaktualniane do protokołu HTTPS/WSS.
• Protokół HTTP Strict Transport Security (HSTS) jest włączony z maksymalnym czasem trwania jednego roku.
• Minimalna wersja protokołu TLS obsługiwana przez usługę to 1.2, a protokół TLS 1.3 jest preferowaną wersją.
• Zakończenie protokołu TLS odbywa się przy wejściu do usługi za pomocą certyfikatów usługowych wystawionych przez urząd certyfikacji firmy Microsoft.
  • Po zakończeniu połączenia TLS następuje przepisanie nagłówków. Jest to wymagane w przypadku wielu scenariuszy tworzenia aplikacji internetowych.

Ochrona przed wyłudzaniem informacji

Podczas pierwszego nawiązywania połączenia z adresem URL przekierowania internetowego użytkownicy widzą pośrednią stronę chroniącą przed wyłudzaniem informacji. Strona jest pomijana w następujących okolicznościach:

• Żądanie używa metody innej niż GET
• Nagłówek żądania Accept nie zawiera text/html
• Żądanie zawiera X-Tunnel-Skip-AntiPhishing-Page nagłówek
• Żądanie zawiera X-Tunnel-Authorization nagłówek
• Użytkownik odwiedził już stronę i kliknął przycisk Kontynuuj

Dostęp do tunelu

Domyślnie tunele i porty tuneli są prywatne i dostępne tylko dla użytkownika, który utworzył tunel.

Jeśli tunel lub port tunelu musi być dostępny bez uwierzytelnienia, można dodać allow-anonymous Access Control Entry (ACE) (użyj --allow-anonymous).

Dostęp do tunelu można również rozszerzyć do bieżącej dzierżawy Microsoft Entra (użyj --tenant) lub określonych organizacji GitHub (użyj --organization); w przypadku tych drugich zobacz sekcję GitHub Organization Access poniżej.

Interfejs wiersza polecenia może również służyć do żądania tokenów dostępu, które udzielają ograniczonego dostępu każdemu, kto posiada token (użyj polecenia devtunnel token). Jest to zaawansowana funkcja, ale może być przydatna w określonych sytuacjach.

Obecnie dostępne są cztery typy tokenów dostępu tunelu:

• "Token dostępu klienta" umożliwia elementowi nośnym nawiązanie połączenia z dowolnymi portami tunelu.
• "Token dostępu hosta" umożliwia posiadaczowi hostowanie tunelu i przyjmowanie połączeń, ale nie pozwala na wprowadzanie żadnych innych zmian w nim.
• Token dostępu do zarządzania portami pozwala posiadaczowi na dodawanie i usuwanie portów w tunelu.
• "Token dostępu do zarządzania" umożliwia elementowi nośnym wykonywanie jakichkolwiek operacji w tym tunelu, w tym ustawianie kontroli dostępu, hostowanie, łączenie i usuwanie tunelu.

Wszystkie tokeny są ograniczone do bieżącego tunelu; nie udzielają dostępu do żadnego z innych tuneli bieżącego użytkownika, jeśli istnieją. Tokeny wygasają po pewnym czasie (obecnie 24 godziny). Tokeny można odświeżać tylko przy użyciu rzeczywistej tożsamości użytkownika, która ma dostęp do uprawnień zarządzania do tunelu (nie tylko token dostępu do zarządzania).

Większość poleceń CLI może przyjmować --access-token argument z odpowiednim tokenem jako alternatywę dla logowania się.

Klienci sieci Web mogą przekazać token w nagłówku, aby autoryzować żądania do identyfikatora URI tunelu:

X-Tunnel-Authorization: tunnel <TOKEN>

Wskazówka

Jest to przydatne w przypadku klientów nieinterakcyjnych, ponieważ umożliwia im dostęp do tuneli bez konieczności włączania dostępu anonimowego. Używamy nagłówka X-Tunnel-Authorization zamiast nagłówka standardowego Authorization , aby zapobiec potencjalnie zakłócaniu autoryzacji specyficznej dla aplikacji.

Zobacz sekcję Zarządzanie dostępem do tunelu deweloperskiego , aby dowiedzieć się więcej na temat zarządzania dostępem do tunelu za pośrednictwem interfejsu wiersza polecenia.

Dostęp do organizacji GitHub

Aby obsługiwać tunele udzielające dostępu do wszystkich członków organizacji usługi GitHub, zainstaluj aplikację GitHub Dev Tunnels w organizacji. To daje usłudze Dev Tunnels uprawnienie do sprawdzania stanu członkostwa użytkowników w tej organizacji. (Tunele Dev nie wymagają uprawnień do repozytoriów w organizacji). Aby wykonać tę operację, możesz potrzebować uprawnień administratora w organizacji usługi GitHub.

Dalsze pytania

Jeśli po przejrzeniu tej strony masz dodatkowe pytania, zobacz Opinie i pomoc techniczna.