Ustawienia usługi VPC – ćwiczenia z programowania dotyczące ochrony BigQuery I

1. Wprowadzenie

Z tego przewodnika dowiesz się, jak chronić interfejs BigQuery API za pomocą Ustawień usługi VPC. W tym samouczku na początku nie ma żadnej usługi API chronionej przez obwód usługi, co umożliwia uruchamianie zapytań dotyczących publicznych zbiorów danych i zapisywanie wyników w tabeli projektu. Zapytanie jest uruchamiane w jednym projekcie, a tabela (w której zapisywane są wyniki) jest tworzona w innym projekcie. Odzwierciedla to konfigurację, w której dane mogą być przechowywane w jednym projekcie, ale dostęp do nich musi być uzyskiwany za pomocą innego projektu.

Następnie wprowadzimy granicę usług, aby chronić projekt dotyczący danych. Dowiesz się, jak naprawić wykryte naruszenia za pomocą reguł ruchu przychodzącego i wychodzącego, a następnie dodać poziom dostępu, aby ograniczyć dostęp za pomocą wewnętrznych adresów IP. Cele tego ćwiczenia:

• Dowiedz się, jak rozwiązywać problemy z naruszeniami reguł dotyczących ruchu przychodzącego i wychodzącego za pomocą odpowiednich reguł.
• Dowiedz się, dlaczego doszło do konkretnego naruszenia.
• Analizowanie zakresu zastosowanej poprawki naruszenia zasad.
• Zmodyfikuj poprawkę (regułę ruchu przychodzącego lub wychodzącego), aby zmienić jej zakres, korzystając z opcji zezwalania na ruch z wewnętrznych adresów IP w sieci VPC za pomocą poziomów dostępu.

2. Konfiguracja zasobów i wymagania

Zanim zaczniesz

W tym module zakładamy, że znasz już:

• Podstawy uruchamiania zapytania BigQuery: w tym samouczku znajdziesz informacje o tym, jak wykonywać zapytania dotyczące zbioru danych Wikipedii w BigQuery.
• Jak utworzyć folder i nim zarządzać
• Jak utworzyć projekt w folderze lub przenieść istniejący projekt do folderu
• Jak utworzyć zasadę dostępu o ograniczonym zakresie
• Jak utworzyć i skonfigurować granicę usług
• Jak znaleźć w logach naruszenia zasad bezpieczeństwa

Konfiguracja

Nasza konfiguracja początkowa wygląda tak:

Jeśli udało Ci się ukończyć podstawowy samouczek dotyczący Ustawień usługi VPC, możesz ponownie użyć tych samych projektów, folderu i granicy usługi.

• organizację Google Cloud;
• folder w organizacji, W tym ćwiczeniu nadamy mu nazwę codelab-folder.
• Dwa projekty Google Cloud umieszczone w tym samym folderze codelab-folder. W tym ćwiczeniu będziemy je oznaczać jako project-1 i project-2.
  • Jeśli nie masz jeszcze utworzonych folderów i projektów, w konsoli Google Cloud utwórz folder w organizacji i utwórz w nim 2 nowe projekty.
• Wymagane uprawnienia:
  • Role uprawnień do zarządzania folderami: przypisywane na poziomie folderu.
  • Role uprawnień do zarządzania projektami: przypisywane na poziomie projektu.
  • Role uprawnień wymagane do skonfigurowania Ustawień usługi VPC: przypisane na poziomie organizacji.
  • Role IAM do zarządzania BigQuery: przypisywane na poziomie projektu.
  • Role uprawnień do zarządzania instancją Compute Engine: przypisywane na poziomie projektu.
• Konto rozliczeniowe dla obu projektów, project-2 i project-1.

Na potrzeby tego samouczka możesz przyznać sobie te predefiniowane role: Administrator folderów i Twórca projektów (na poziomie folderu), Właściciel (na poziomie projektu), Administrator BigQuery (na poziomie projektu) i Administrator Menedżera kontekstu dostępu (na poziomie organizacji). Dzięki temu będziesz mieć role wymagane do skonfigurowania zasobów potrzebnych do ukończenia tego samouczka.

Tworzenie standardowej granicy usług

W tym ćwiczeniu użyjemy zwykłej granicy usług chroniącej project-1.

• Utwórz zwykłą granicę, perimeter-1 i dodaj project-1.

W obrębie granicy nie ograniczaj jeszcze żadnej usługi. Zrobimy to później.

Tworzenie maszyny wirtualnej Compute Engine

W tym module użyjemy 1 instancji Compute Engine w project-2, która znajduje się w us-central1 i korzysta z domyślnej sieci VPC o nazwie default.

• W dokumentacji znajdziesz wskazówki dotyczące tworzenia instancji Compute Engine na podstawie obrazu publicznego.

W tym samouczku użyjemy domyślnej sieci VPC o nazwie default. Możesz też użyć dowolnej innej sieci, o ile ma ona co najmniej 1 podsieć.

Koszt

Aby korzystać z zasobów i interfejsów API w chmurze, musisz włączyć rozliczenia w konsoli Google Cloud. Zalecamy wyłączenie używanych zasobów, aby uniknąć naliczania opłat po zakończeniu tego samouczka. Nowi użytkownicy Google Cloud mogą skorzystać z programu bezpłatnego okresu próbnego, w którym mają do dyspozycji środki w wysokości 300 USD.

Zasoby, które generują koszty, to BigQuery i instancja Compute Engine. Koszt możesz oszacować za pomocą kalkulatora cen BigQuery i kalkulatora cen Compute Engine.

3. Dostęp do BigQuery bez ograniczeń Ustawień usługi VPC

Tworzenie zapytania dotyczącego publicznego zbioru danych i zapisywanie wyników w project-1

1. Otwórz project-2 i project-1, aby sprawdzić, czy masz dostęp do interfejsu BigQuery API. W tym celu otwórz stronę BigQuery Studio. Powinno się to udać, ponieważ nawet jeśli project-1 znajduje się w granicy usług, nie chroni ona jeszcze żadnej usługi.
2. W project-2 uruchom to zapytanie, aby utworzyć zapytanie dotyczące publicznego zbioru danych.

SELECT  name, SUM(number) AS total
FROM  `bigquery-public-data.usa_names.usa_1910_2013`
GROUP BY   name
ORDER BY total DESC
LIMIT 10;

Po uruchomieniu zapytania dotyczącego publicznego zbioru danych (pozostając w project-2):

1. Kliknij Zapisz wyniki i wybierz Tabela BigQuery. (patrz zrzut ekranu poniżej).
2. Wybierz project-1 jako projekt docelowy.
3. Nadaj zbiorowi danych nazwę codelab_dataset. (Wybierz UTWÓRZ NOWY ZBIÓR DANYCH, chyba że używasz istniejącego zbioru danych).
4. Nazwij tabelę: codelab-table.
5. Kliknij Zapisz.

Dane z publicznego zbioru danych zostały zapisane w project-1 w wyniku wykonania zapytania z project-2.

Zapisano zestaw danych zapytania w project-1 z project-2

W project-2 BigQuery Studio wykonaj to zapytanie, aby wybrać dane z:

• Projekt: project-1
• Zbiór danych: codelab_dataset
• Tabela: codelab-table

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

Zapytanie powinno zostać uruchomione, ponieważ ani project-2, ani project-1 nie mają ograniczeń dotyczących korzystania z BigQuery. Dostęp do BigQuery jest możliwy z dowolnego miejsca, o ile użytkownik ma odpowiednie uprawnienia IAM.

Ten diagram ilustruje proces, który zachodzi, gdy podmiot wykonuje zapytanie dotyczące zbioru danych BigQuery. Każde zapytanie BigQuery inicjuje zadanie BigQuery, które wykonuje rzeczywistą operację, w tym przypadku pobieranie danych. Dostęp podmiotu jest demonstrowany z instancji Compute Engine i z internetu podczas wysyłania zapytań do publicznego zbioru danych i z osobnego projektu Google Cloud. Proces wysyłania zapytań o dane (GetData) przebiega pomyślnie i nie jest blokowany przez Ustawienia usługi VPC.

4. Ochrona interfejsu BigQuery API w projekcie źródłowego zbioru danych

Zmodyfikuj konfigurację granicy perimeter-1 i ogranicz usługę BigQuery API wraz z chronionym zasobem project-1.

Weryfikowanie egzekwowania granic usług

W project-2 uruchom w BigQuery Studio to zapytanie, tak jak w poprzednim kroku:

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

Nastąpi naruszenie RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER Ustawień usługi VPC

Dziennik kontrolny naruszeń będzie się znajdować w project-1, ponieważ tam doszło do naruszenia polegającego na przekroczeniu granicy. Dzienniki można filtrować za pomocą obserwowanego vpcServiceControlsUniqueId (zastąp VPC_SC_DENIAL_UNIQUE_ID obserwowanym unikalnym identyfikatorem).

severity=ERROR
resource.type="audited_resource"
protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="[*VPC_SC_DENIAL_UNIQUE_ID*]"

Naruszenie to egressViolations:

• principalEmail: [konto użytkownika, który uruchomił zapytanie]
• callerIp: [Adres IP agenta użytkownika, który uruchomił zapytanie]

     "egressViolations": [
       {
         "targetResource": "projects/project-2",
         "sourceType": "Resource",
         "source": "projects/project-1",
         "servicePerimeter": "accessPolicies/REDACTED/servicePerimeters/perimeter-1",
         "targetResourcePermissions": [ "bigquery.jobs.create"]
       }      ],

5. Naprawianie naruszenia w celu utworzenia zadania BigQuery

Naruszanie Ustawień usługi VPC ma uprawnienie docelowe bigquery.jobs.create ze względu na sposób działania BigQuery. Gdy używasz konsoli Google Cloud (lub narzędzia wiersza poleceń bq) do zarządzania danymi BigQuery, BigQuery tworzy zadania, które są następnie wykorzystywane do wykonywania żądanych działań. Pierwszym zdarzeniem jest utworzenie zadania BigQuery.

Ten diagram ilustruje sytuację, w której podmiot uruchamia zapytanie z project-2 dotyczące zbioru danych w project-1. Operacja tworzenia zadania BigQuery z projektu zbioru danych (project-1) w projekcie, z którego uruchamiane jest zapytanie (project-2), kończy się niepowodzeniem z powodu naruszenia zasad wychodzących Ustawień usługi VPC spowodowanego przez granicę usługi perimeter-1 chroniącą interfejs BigQuery API. Po utworzeniu granicy żadne żądanie interfejsu BigQuery API nie może być inicjowane z project-1 na zewnątrz granicy ani inicjowane poza granicą w kierunku chronionego projektu, chyba że zezwalają na to konfiguracje granicy usługi.

Naruszenie zasad dotyczących ruchu wychodzącego można naprawić, tworząc regułę ruchu wychodzącego na podstawie:

• źródło (OD): adres e-mail użytkownika i kontekst (np.adres IP dzwoniącego, stan urządzenia, lokalizacja itp.);
• miejsce docelowe (TO): zasób docelowy, usługa i metoda lub uprawnienie.

Aby naprawić wykryte naruszenie reguły ruchu wychodzącego, utwórz regułę ruchu wychodzącego, która zezwala na ruch w kierunku zasobu docelowego (project-2) z konta użytkownika uruchamiającego zapytanie ([e-mail]) w usłudze BigQuery oraz metodę/ uprawnienie bigquery.jobs.create.

Oczekiwane działanie skonfigurowanej reguły ruchu wychodzącego:

• FROM | Tożsamości: tylko określona tożsamość [e-mail] musi mieć uprawnienia do przekraczania granicy obszaru.
• TO | projects: określona tożsamość może przekraczać granice obszaru tylko wtedy, gdy miejscem docelowym jest określony projekt project-2.
• TO | Usługi: określona tożsamość może inicjować ruch poza obszarem, w kierunku określonego projektu, tylko wtedy, gdy wywołanie interfejsu API dotyczy określonej usługi i metody. W przeciwnym razie, np. jeśli użytkownik spróbuje użyć innej usługi chronionej przez granicę usług, operacja zostanie zablokowana, ponieważ inne usługi są niedozwolone.

Testowanie poprawki: reguła dla ruchu wychodzącego

Po utworzeniu reguły wyjścia uruchom to samo zapytanie.

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

Nastąpi kolejne naruszenie, tym razem będzie to naruszenie dotyczące NO_MATCHING_ACCESS_LEVEL. Nowe naruszenie różni się od pierwszego pod względem projektu docelowego i metody.

Naprawienie jednego naruszenia ustawień usługi VPC nie oznacza, że nie wystąpią inne naruszenia. Nowe wywołanie interfejsu API z kontekstem innym niż te, które są dozwolone przez skonfigurowane już zasady, spowoduje inne naruszenie.

Nowe naruszenie to naruszenie dotyczące ruchu przychodzącego, które

• principalEmail: [konto użytkownika, który uruchomił zapytanie]
• callerIp: [Adres IP agenta użytkownika, który uruchomił zapytanie]

ingressViolations: [
0: {
 servicePerimeter: "accessPolicies/REDACTED/servicePerimeters/perimeter-1"
 targetResource: "projects/project-1"
 targetResourcePermissions: [0: "bigquery.tables.getData"]}
 ]

Naruszenie w przypadku metody bigquery.tables.getData jest spowodowane wywołaniem interfejsu API zainicjowanym przez zadanie BigQuery, które próbuje pobrać dane z tabeli BigQuery.

Aby przewidzieć spodziewane naruszenia, warto zrozumieć, jak działa dana usługa API.

6. Rozwiązywanie problemów z naruszeniami zasad w celu uzyskania danych z tabeli BigQuery

Reguła dostępu przychodzącego naprawia naruszenie dostępu przychodzącego, zapewniając szczegółową kontrolę nad tym, kto może przekraczać granicę perymetru usługi, a także nad kontekstem dozwolonego dostępu, takim jak projekt źródłowy lub docelowy oraz metoda interfejsu API, do której użytkownik ma dostęp.

Naruszenie zasad dotyczących ruchu przychodzącego jest naprawiane przez regułę ruchu przychodzącego skonfigurowaną w ten sposób:

• źródło (OD): adres e-mail użytkownika i kontekst (np.adres IP dzwoniącego, stan urządzenia, lokalizacja itp.);
• miejsce docelowe (TO): zasób docelowy, usługa i metoda lub uprawnienie.

Reguła ruchu przychodzącego zezwoli na ruch w kierunku project-1 ze strony określonego użytkownika w przypadku określonej usługi i metody.

Oczekiwane działanie skonfigurowanej reguły ruchu przychodzącego:

• FROM | Tożsamości: tylko określona tożsamość [e-mail] musi mieć uprawnienia do przekraczania granicy obszaru.
• TO | projects: określona tożsamość może przekraczać granice obszaru tylko wtedy, gdy miejscem docelowym jest określony projekt project-1.
• TO | Usługi: określona tożsamość może inicjować ruch wewnątrz obszaru tylko wtedy, gdy wywołanie interfejsu API dotyczy BigQuery API i określonej metody bigquery.tables.getData.

Wykonanie identycznego zapytania powinno odtąd działać prawidłowo bez naruszania ustawień usługi VPC.

Ograniczyliśmy dostęp do interfejsu BigQuery API w project-1, tak aby mógł być używany tylko przez [e-mail], a nie przez [e-mail].

Ten diagram pokazuje, jak 2 różne podmioty próbują wysłać zapytanie do tego samego zbioru danych. Dostęp przez [e-mail] (niebieskie linie przerywane) jest blokowany przez ustawienia usługi VPC, ponieważ konfiguracja granicy usługi nie zezwala na uruchamianie operacji BigQuery z project-1 ani w jej kierunku. Dostęp użytkownika [e-mail] (zielona linia ciągła) jest możliwy, ponieważ konfiguracje ustawień usługi VPC zezwalają mu na wykonywanie operacji z i do project-1.

7. Ograniczanie ruchu dozwolonego przez granicę usług na podstawie wewnętrznego adresu IP

Obecna konfiguracja umożliwia wyznaczonemu użytkownikowi uruchamianie zapytań w BigQuery w project-1 z dowolnej lokalizacji, czyli z dowolnego miejsca w internecie, jeśli ma on uprawnienia IAM do wykonywania zapytań dotyczących danych i korzysta ze swojego konta. Z punktu widzenia bezpieczeństwa oznacza to, że jeśli konto zostanie przejęte, każda osoba, która uzyska do niego dostęp, będzie mogła uzyskać dostęp do danych BigQuery bez żadnych dodatkowych ograniczeń.

Dalsze ograniczenia można wprowadzić, korzystając z poziomu dostępu w regułach ruchu przychodzącego i wychodzącego, aby określić kontekst użytkownika. Możesz na przykład zezwolić na dostęp na podstawie źródłowego adresu IP w połączeniu z wcześniej skonfigurowaną regułą wejścia, która autoryzuje dostęp na podstawie tożsamości wywołującego. Dostęp według źródłowego adresu IP jest możliwy w przypadku zakresów CIDR publicznych adresów IP, pod warunkiem że klient użytkownika ma przypisany publiczny adres IP, lub przy użyciu wewnętrznego adresu IP, jeśli klient użytkownika działa w projekcie Google Cloud.

Tworzenie poziomu dostępu z warunkiem dostępu na podstawie wewnętrznego adresu IP

W tym samym folderze zasad dostępu o ograniczonym zakresie otwórz stronę Menedżera kontekstu dostępu, aby utworzyć poziom dostępu.

1. Na stronie Menedżer kontekstu dostępu kliknij UTWÓRZ POZIOM DOSTĘPU.
2. W panelu Nowy poziom dostępu:
   1. Podaj tytuł: możesz użyć codelab-al.
   2. W sekcji Warunki kliknij Podsieci IP.
   3. Wybierz kartę Prywatny adres IP i kliknij WYBIERZ SIECI VPC.
   4. W panelu Dodaj sieci VPC możesz przeglądać i wyszukiwać sieć default lub ręcznie wpisać pełną nazwę sieci w formacie //compute.googleapis.com/projects/project-2/global/networks/default.
   5. Kliknij DODAJ SIEĆ VPC.
   6. Kliknij WYBIERZ PODSIECI IP.
   7. Wybierz region, w którym znajduje się instancja maszyny wirtualnej. W tym ćwiczeniu jest to us-central1.
   8. Kliknij ZAPISZ.

Utworzyliśmy poziom dostępu, który nie jest jeszcze wymuszany w żadnych zasadach dotyczących perymetrów ani zasadach dotyczących ruchu przychodzącego i wychodzącego.

Dodawanie poziomu dostępu do reguły dla ruchu przychodzącego

Aby wymusić, aby użytkownik, na którego zezwala reguła wejścia, był również weryfikowany pod kątem poziomu dostępu, należy skonfigurować poziom dostępu w regule wejścia. Reguła wejścia, która autoryzuje dostęp do danych zapytań, znajduje się w perimeter-1. Zmień regułę dostępu przychodzącego, aby zdefiniować źródło jako poziom dostępu codelab-al.

Testowanie nowych konfiguracji

Po dodaniu poziomu dostępu do reguły dostępu przychodzącego to samo zapytanie BigQuery nie powiedzie się, chyba że zostanie wykonane z klienta w sieci VPC default w projekcie project-2. Aby sprawdzić to zachowanie, wykonaj zapytanie w konsoli Google Cloud, gdy urządzenie punktu końcowego jest połączone z internetem. Zapytanie zakończy się niepowodzeniem, a wraz z nim pojawi się informacja o naruszeniu zasad dotyczących danych przychodzących.

Domyślnie:

• Zakres dostępu instancji Compute Engine jest domyślnie ustawiony na domyślny dostęp, który nie zezwala na dostęp do BigQuery API.
• Instancja Compute Engine będzie miała dołączone domyślne konto usługi Compute Engine. Wszystkie polecenia uruchamiane na maszynie wirtualnej będą wykonywane jako to konto usługi, które musi mieć format [e-mail].
  Zarówno zakres dostępu, jak i konto usługi dołączone do maszyny wirtualnej można zmienić.

To samo zapytanie można uruchomić z sieci VPC default znajdującej się w lokalizacji project-2. Podobnie wykonanie tego samego zapytania BigQuery z instancji Compute Engine znajdującej się w regionie project-2 przy użyciu sieci VPC default również się nie powiedzie. Dzieje się tak, ponieważ reguła wejścia jest nadal skonfigurowana tak, aby zezwalać tylko podmiotowi zabezpieczeń [e-mail]. Maszyna wirtualna używa jednak domyślnego konta usługi Compute Engine.

Aby uruchomić to samo polecenie z instancji Compute Engine w project-2, upewnij się, że:

• Maszyna wirtualna ma zakres dostępu umożliwiający korzystanie z interfejsu BigQuery API. Możesz to zrobić, wybierając Zezwól na pełny dostęp do wszystkich interfejsów Cloud APIs jako zakres dostępu maszyny wirtualnej.
• Konto usługi dołączone do maszyny wirtualnej musi mieć uprawnienia IAM do:
  • Tworzenie zadań BigQuery w project-2
  • Pobierz dane BigQuery z tabeli BigQuery znajdującej się w project-1.
• Domyślne konto usługi Compute Engine musi być dozwolone przez regułę ruchu przychodzącego i wychodzącego.

Teraz musimy dodać domyślne konto usługi Compute Engine do reguł ruchu przychodzącego (aby umożliwić pobieranie danych z tabeli BigQuery) i do reguły ruchu wychodzącego (aby umożliwić tworzenie zadań BigQuery).

Na instancji Compute Engine w project-2 w sieci VPC default uruchom to polecenie bq query:

bq query --nouse_legacy_sql \
'SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;'

Przy obecnej konfiguracji polecenie BigQuery zostanie wykonane tylko wtedy, gdy:

• działać na maszynie wirtualnej korzystającej z domyślnej sieci VPC w project-2,
• znajduje się w określonym regionie us-central1 (podsieć IP),
• działać przy użyciu domyślnego konta usługi Compute Engine skonfigurowanego w obszarze usługi.

Polecenie zapytania BigQuery nie powiedzie się, jeśli zostanie uruchomione w innych miejscach, w tym:

• jeśli jest uruchamiana na maszynie wirtualnej korzystającej z domyślnej sieci VPC w project-2, ale znajduje się w innym regionie niż podsieć dodana na poziomie dostępu, lub
• jeśli jest uruchamiany przez uż[e-mail] za pomocą klienta użytkownika w internecie.

 Ten diagram ilustruje dostęp inicjowany przez tego samego uczestnika, [e-mail], z dwóch różnych lokalizacji: internetu i instancji Compute Engine. Dostęp do BigQuery bezpośrednio z internetu (niebieskie linie przerywane) jest blokowany przez ustawienia usługi VPC, natomiast dostęp z maszyny wirtualnej (zielone linie ciągłe) – podczas przyjmowania tożsamości domyślnego konta usługi Compute Engine – jest dozwolony. Dozwolony dostęp wynika z tego, że granica usługi jest skonfigurowana tak, aby zezwalać na dostęp do zabezpieczonych zasobów z wewnętrznego adresu IP.

8. Czyszczenie

Za korzystanie z Ustawień usługi VPC, gdy usługa nie jest używana, nie są naliczane żadne opłaty, ale zalecamy wyczyszczenie konfiguracji użytej w tym laboratorium. Aby uniknąć naliczania opłat, możesz też usunąć instancję maszyny wirtualnej i zbiory danych BigQuery lub projekty Google Cloud. Usunięcie projektu w Google Cloud spowoduje zaprzestanie naliczania opłat za wszystkie zasoby wykorzystywane w ramach tego projektu.

• Aby usunąć instancję maszyny wirtualnej, wykonaj te czynności:
  • W konsoli Google Cloud otwórz stronę Instancje maszyn wirtualnych.
  • Zaznacz pole wyboru po lewej stronie nazwy instancji maszyny wirtualnej, a następnie kliknij Usuń. Aby potwierdzić, ponownie kliknij Usuń.
• Aby usunąć granicę usług, wykonaj te czynności:
  • W konsoli Google Cloud wybierz Zabezpieczenia, a następnie Ustawienia usługi VPC na poziomie, na którym jest określony zakres zasad dostępu, w tym przypadku na poziomie folderu.
  • Na stronie Ustawienia usługi VPC w wierszu tabeli odpowiadającym granicy, którą chcesz usunąć, kliknij Usuń.
• Aby usunąć poziom dostępu, wykonaj te czynności:
  • W konsoli Google Cloud otwórz stronę Menedżer kontekstu dostępu w zakresie folderu.
  • W siatce znajdź wiersz poziomu dostępu, który chcesz usunąć, kliknij menu z 3 kropkami, a potem wybierz Usuń.
• Aby zamknąć projekty, wykonaj te czynności:
  • W konsoli Google Cloud otwórz stronę Ustawienia w obszarze Administracja projektu, który chcesz usunąć.
  • Na stronie Ustawienia w obszarze Administracja kliknij Wyłącz.
  • Wpisz identyfikator projektu i kliknij Wyłącz mimo to.

9. Gratulacje!

W tym ćwiczeniu utworzyliśmy granicę Ustawień usługi VPC, wymusiliśmy jej stosowanie i rozwiązaliśmy problemy z nią związane.

Więcej informacji

Możesz też sprawdzić te scenariusze:

• Uruchom to samo zapytanie w publicznym zbiorze danych po zabezpieczeniu projektu za pomocą ustawień usługi VPC.
• Dodaj project-2 w tym samym obwodzie co project-1.
• Dodaj project-2 do własnej granicy i pozostaw project-1 w bieżącej granicy.
• Uruchamiać zapytania, aby aktualizować dane w tabeli, a nie tylko je pobierać.

Licencja

To zadanie jest licencjonowane na podstawie ogólnej licencji Creative Commons Attribution 2.0.