Udostępnij za pośrednictwem

Zabezpieczenia

  • Artykuł

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

Omówienie

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 maksymalną rokiem.
  • 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ę w przypadku ruchu przychodzącego usługi przy użyciu certyfikatów usługi wystawionych przez urząd certyfikacji firmy Microsoft.
    • Po zakończeniu uwierzytelniania TLS następuje ponowne zapisywanie nagłówka. Jest to wymagane w przypadku wielu scenariuszy tworzenia aplikacji internetowych.

Ochrona przed wyłudzaniem informacji

Podczas nawiązywania połączenia z adresem URL przekazywania internetowego po raz pierwszy użytkownicy są prezentowani z interstytucyjną 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 dostęp do tunelu lub portu tunelu musi być uzyskiwany bez uwierzytelniania, można dodać wpis kontroli dostępu (ACE, allow-anonymous Access Control Entry) (użyj polecenia --allow-anonymous).

Dostęp do tunelu można również rozszerzyć do bieżącej dzierżawy firmy Microsoft Entra (użyj --tenant) lub określonych organizacji usługi GitHub (użyj --organizationprogramu ); aby uzyskać ten ostatni dostęp do organizacji w usłudze GitHub 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 elementu nośnego hostowanie tunelu i akceptowanie połączeń, ale nie wprowadza żadnych innych zmian w nim.
  • Opcja "Zarządzanie tokenem dostępu portów" umożliwia elementowi nośnym 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 zakresu zarządzania do tunelu (nie tylko token dostępu do zarządzania).

Większość poleceń interfejsu wiersza polecenia może akceptować --access-token argument z odpowiednim tokenem jako alternatywą dla logowania.

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

X-Tunnel-Authorization: tunnel <TOKEN>

Napiwek

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 w usłudze 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 deweloperskie nie wymagają uprawnień repozytorium do organizacji). Aby wykonać tę operację, może być administratorem w organizacji usługi GitHub.

Dalsze pytania

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