WEBVTT

00:00:00.200 --> 00:00:01.680
Wyobraź sobie taką sytuację.

00:00:01.920 --> 00:00:04.940
Budujesz aplikację i potrzebujesz klucza API do połączenia z usługą,

00:00:05.060 --> 00:00:07.280
hasła do bazy danych lub klucza konta magazynu.

00:00:07.420 --> 00:00:08.700
Więc umieszczasz go w swoim kodzie,

00:00:08.860 --> 00:00:11.260
może w pliku konfiguracyjnym lub zmiennej środowiskowej.

00:00:11.480 --> 00:00:12.940
Działa, wszystko uruchamia się poprawnie,

00:00:13.060 --> 00:00:14.340
dopóki nie wypchniesz kodu na GitHub

00:00:14.340 --> 00:00:16.500
lub nie udostępnisz notatnika współpracownikowi.

00:00:16.640 --> 00:00:19.180
I w jednej chwili Twój sekret przestaje być sekretem.

00:00:19.360 --> 00:00:21.220
Jeśli ten kod wpadnie w niepowołane ręce,

00:00:21.420 --> 00:00:22.940
cały Twój system jest zagrożony.

00:00:23.160 --> 00:00:25.860
Azure Key Vault to narzędzie, które rozwiązuje ten problem.

00:00:26.140 --> 00:00:28.240
Daje Ci bezpieczne miejsce do przechowywania sekretów,

00:00:28.240 --> 00:00:29.480
aby nigdy nie trafiły do kodu.

00:00:29.680 --> 00:00:31.940
Ale oto rzecz, w której większość ludzi popełnia błąd.

00:00:32.080 --> 00:00:34.060
Samo posiadanie Key Vault nie sprawia automatycznie,

00:00:34.180 --> 00:00:35.000
że jesteś bezpieczny.

00:00:35.220 --> 00:00:37.060
Sposób konfiguracji, kontroli dostępu

00:00:37.060 --> 00:00:38.880
i przyznawania uprawnień jest równie ważny.

00:00:39.060 --> 00:00:40.520
Pod koniec tego odcinka dowiesz się,

00:00:40.620 --> 00:00:41.700
czym właściwie jest Key Vault,

00:00:41.840 --> 00:00:42.880
co możesz w nim przechowywać,

00:00:43.020 --> 00:00:44.980
jak działa dostęp i jaki jest największy błąd,

00:00:45.040 --> 00:00:46.880
przez który Twoje sekrety mogą wycieknąć.

00:00:47.060 --> 00:00:48.820
Wszystko prostym językiem, bez żargonu,

00:00:48.880 --> 00:00:49.980
tylko to, co musisz wiedzieć.

00:00:49.980 --> 00:00:52.000
Czym więc dokładnie jest Azure Key Vault?

00:00:52.180 --> 00:00:53.440
Czym jest Azure Key Vault?

00:00:53.620 --> 00:00:55.020
Oto najprostsza definicja.

00:00:55.020 --> 00:00:58.280
Azure Key Vault to chmurowy, cyfrowy sejf na Twoje sekrety.

00:00:58.440 --> 00:01:00.500
To zarządzana usługa Microsoftu na klucze API,

00:01:00.700 --> 00:01:02.480
hasła do baz danych, ciągi połączeniowe,

00:01:02.620 --> 00:01:04.040
klucze szyfrujące i certyfikaty

00:01:04.040 --> 00:01:05.300
w jednym centralnym miejscu.

00:01:05.460 --> 00:01:06.840
Nie musisz martwić się o infrastrukturę,

00:01:06.900 --> 00:01:08.460
ponieważ Azure zajmuje się aktualizacjami,

00:01:08.560 --> 00:01:09.760
dostępnością i bezpieczeństwem.

00:01:09.860 --> 00:01:11.180
Ty po prostu z niego korzystasz.

00:01:11.340 --> 00:01:12.940
Pomyśl o tym jak o budynku biurowym.

00:01:13.180 --> 00:01:14.020
Masz stanowiska pracy,

00:01:14.160 --> 00:01:15.520
sale spotkań i szafki na dokumenty,

00:01:15.520 --> 00:01:17.480
ale gdzieś w piwnicy jest bezpieczny skarbiec,

00:01:17.560 --> 00:01:18.600
w którym trzymasz ważne rzeczy.

00:01:18.600 --> 00:01:20.840
Główne klucze, gotówkę, dokumenty prawne.

00:01:21.000 --> 00:01:23.180
Nikt nie wchodzi tam bez pozwolenia i uwierzytelnienia,

00:01:23.360 --> 00:01:25.520
a każde otwarcie drzwi jest rejestrowane w logach.

00:01:25.680 --> 00:01:26.820
Taki właśnie jest Key Vault.

00:01:27.080 --> 00:01:29.580
Bezpieczny pokój w piwnicy Twojej architektury Azure.

00:01:29.800 --> 00:01:31.700
Teraz porównaj to ze starym sposobem.

00:01:31.880 --> 00:01:34.440
20 lat temu, jeśli potrzebowałeś hasła do bazy danych,

00:01:34.560 --> 00:01:36.600
wpisywałeś je na sztywno w pliku konfiguracyjnym,

00:01:36.740 --> 00:01:38.000
może w zmiennej środowiskowej,

00:01:38.080 --> 00:01:38.580
albo gorzej,

00:01:38.680 --> 00:01:40.660
zostawiałeś je w czystym tekście w kodzie źródłowym.

00:01:40.900 --> 00:01:42.760
Jeśli ktoś uzyskał dostęp do serwera,

00:01:42.820 --> 00:01:43.340
miał wszystko.

00:01:43.560 --> 00:01:45.160
A jeśli musiałeś zmienić to hasło,

00:01:45.160 --> 00:01:46.780
musiałeś aktualizować je wszędzie.

00:01:46.980 --> 00:01:48.180
W każdym pliku konfiguracyjnym,

00:01:48.300 --> 00:01:49.060
w każdym środowisku,

00:01:49.180 --> 00:01:49.880
w każdym wdrożeniu.

00:01:50.000 --> 00:01:50.700
To był koszmar.

00:01:50.880 --> 00:01:52.200
Key Vault zmienia to wszystko.

00:01:52.500 --> 00:01:55.000
Zamiast rozpraszać sekrety w kodzie i plikach konfiguracyjnych,

00:01:55.120 --> 00:01:56.820
przechowujesz je w jednym centralnym miejscu.

00:01:57.000 --> 00:01:58.820
Twoje aplikacje pobierają je w czasie działania,

00:01:58.940 --> 00:02:00.260
tylko wtedy, gdy ich potrzebują.

00:02:00.460 --> 00:02:02.120
A ponieważ wszystko jest scentralizowane,

00:02:02.240 --> 00:02:03.800
możesz zmienić klucz w jednym miejscu,

00:02:03.860 --> 00:02:05.580
a każda aplikacja, która z niego korzysta,

00:02:05.720 --> 00:02:07.160
automatycznie pobierze nową wartość

00:02:07.160 --> 00:02:08.840
bez zmian w kodzie czy ponownego wdrażania.

00:02:08.840 --> 00:02:10.620
Ale rzecz w tym, że Key Vault to nie tylko

00:02:10.620 --> 00:02:12.280
menedżer haseł dla Twoich aplikacji.

00:02:12.420 --> 00:02:14.120
To podstawowa usługa bezpieczeństwa.

00:02:14.340 --> 00:02:16.480
Każda usługa Azure może się z nią zintegrować.

00:02:16.640 --> 00:02:18.660
App Service, funkcje, AKS, data factory,

00:02:18.840 --> 00:02:20.400
Synapse, Logic Apps, potoki DevOps,

00:02:20.540 --> 00:02:22.180
wszystkie potrafią komunikować się z Key Vault.

00:02:22.440 --> 00:02:25.060
Staje się on kręgosłupem Twojej bezpiecznej architektury chmurowej.

00:02:25.200 --> 00:02:26.680
A kiedy już go poprawnie skonfigurujesz,

00:02:26.800 --> 00:02:28.960
całkowicie przestajesz myśleć o zarządzaniu poświadczeniami.

00:02:29.140 --> 00:02:30.380
Co można w nim przechowywać?

00:02:30.600 --> 00:02:32.020
Skoro wiesz już, czym jest Key Vault,

00:02:32.160 --> 00:02:34.620
porozmawiajmy o tym, co faktycznie możesz w nim umieścić.

00:02:34.620 --> 00:02:37.900
Masz trzy główne kategorie, sekrety, klucze i certyfikaty.

00:02:38.100 --> 00:02:39.700
Każda z nich służy do czegoś innego,

00:02:39.820 --> 00:02:42.580
a zrozumienie tej różnicy pomoże Ci właściwie korzystać z Key Vault.

00:02:42.920 --> 00:02:44.040
Zacznijmy od sekretów.

00:02:44.160 --> 00:02:46.160
To najczęstsza rzecz, którą ludzie przechowują.

00:02:46.420 --> 00:02:48.120
Sekrety to parametry połączeń, klucze API,

00:02:48.300 --> 00:02:49.960
hasła do baz danych, klucze konta magazynu,

00:02:49.980 --> 00:02:51.380
w zasadzie wszystkie codzienne poświadczenia,

00:02:51.540 --> 00:02:53.960
których aplikacje potrzebują do komunikacji z innymi usługami.

00:02:54.180 --> 00:02:56.480
Zamiast umieszczać je w kodzie lub pliku konfiguracyjnym,

00:02:56.600 --> 00:02:57.580
przechowujesz je w Key Vault.

00:02:57.780 --> 00:02:59.320
Twoja aplikacja pobiera je w czasie wykonywania

00:02:59.320 --> 00:03:01.220
i nikt nigdy nie widzi ich w postaci czystego tekstu.

00:03:01.320 --> 00:03:02.740
Pomyśl o tym, jak o zamkniętej szufladzie

00:03:02.740 --> 00:03:04.120
w Twojej cyfrowej szafce na dokumenty.

00:03:04.320 --> 00:03:05.760
Następne w kolejności są klucze.

00:03:05.920 --> 00:03:07.760
To klucze szyfrujące dla danych w spoczynku.

00:03:07.980 --> 00:03:09.780
Jeśli używasz kluczy zarządzanych przez klienta

00:03:09.780 --> 00:03:11.320
dla Azure Storage, baz danych SQL

00:03:11.320 --> 00:03:13.000
lub szyfrowania dysków maszyn wirtualnych,

00:03:13.080 --> 00:03:14.540
te klucze mogą znajdować się w Key Vault.

00:03:14.760 --> 00:03:16.180
Daje Ci to pełną kontrolę nad tym,

00:03:16.280 --> 00:03:17.620
kto i kiedy może z nich korzystać.

00:03:17.700 --> 00:03:19.120
A jeśli ze względu na zgodność

00:03:19.120 --> 00:03:20.400
potrzebujesz kluczy sprzętowych,

00:03:20.540 --> 00:03:22.220
wersja premium zapewnia ochronę HSM.

00:03:22.220 --> 00:03:23.620
Potem mamy certyfikaty.

00:03:23.820 --> 00:03:25.240
Certyfikaty TLS i SSL

00:03:25.240 --> 00:03:26.640
dla Twoich aplikacji internetowych,

00:03:26.760 --> 00:03:27.820
API i usług wewnętrznych.

00:03:27.960 --> 00:03:28.940
Key Vault może je przechowywać,

00:03:29.040 --> 00:03:29.940
zarządzać ich cyklem życia,

00:03:30.040 --> 00:03:31.140
a nawet automatycznie odnawiać,

00:03:31.220 --> 00:03:32.620
gdy zbliża się termin ich wygaśnięcia.

00:03:32.760 --> 00:03:33.800
To ratunek dla każdego,

00:03:33.960 --> 00:03:35.880
komu certyfikat wygasł kiedyś w niedzielę

00:03:35.880 --> 00:03:36.780
o trzeciej nad ranem.

00:03:36.960 --> 00:03:37.940
Oto przykład z życia.

00:03:38.220 --> 00:03:39.960
Wyobraź sobie, że masz aplikację internetową,

00:03:40.080 --> 00:03:41.700
która potrzebuje ciągu połączenia z bazą danych

00:03:41.700 --> 00:03:43.200
i klucza API dla usługi zewnętrznej.

00:03:43.380 --> 00:03:45.520
W starym stylu umieściłbyś oba w pliku JSON

00:03:45.520 --> 00:03:46.620
z ustawieniami aplikacji.

00:03:46.840 --> 00:03:48.880
Jeśli ten plik trafi do Twojego repozytorium,

00:03:49.040 --> 00:03:50.280
każdy, kto ma dostęp do kodu,

00:03:50.440 --> 00:03:51.980
zobaczy Twoje poświadczenia bazy danych.

00:03:52.220 --> 00:03:54.600
Dzięki Key Vault przechowujesz obie wartości jako sekrety.

00:03:54.820 --> 00:03:56.260
Aplikacja pobiera je podczas uruchamiania

00:03:56.260 --> 00:03:57.880
i nigdy nie pojawiają się one w kodzie źródłowym.

00:03:58.100 --> 00:03:59.640
Musisz zmienić hasło do bazy danych?

00:03:59.980 --> 00:04:01.000
Zaktualizuj je w Key Vault.

00:04:01.220 --> 00:04:03.080
Aplikacja automatycznie pobierze nową wartość

00:04:03.080 --> 00:04:04.000
przy kolejnym restarcie.

00:04:04.200 --> 00:04:05.880
Bez zmian w kodzie, bez ponownego wdrażania.

00:04:06.100 --> 00:04:07.600
Jedną z rzeczy, która zaskakuje użytkowników,

00:04:07.660 --> 00:04:08.680
jest wbudowana obsługa wersji.

00:04:08.680 --> 00:04:10.400
Podczas aktualizacji wpisu tajnego Key Vault

00:04:10.400 --> 00:04:11.560
nie nadpisuje starej wartości.

00:04:11.740 --> 00:04:12.720
Tworzy nową wersję.

00:04:12.960 --> 00:04:14.080
Stare wersje są zachowywane,

00:04:14.160 --> 00:04:16.200
więc w razie problemów można przywrócić poprzedni stan.

00:04:16.340 --> 00:04:18.360
To niezwykle przydatne podczas incydentów.

00:04:18.580 --> 00:04:20.360
Możesz szybko wrócić do poprzedniego wpisu

00:04:20.360 --> 00:04:22.620
bez konieczności pamiętania jego starej wartości.

00:04:22.860 --> 00:04:24.520
W tym samym magazynie możesz przechowywać

00:04:24.520 --> 00:04:27.040
wszystkie trzy typy, wpisy tajne, klucze i certyfikaty.

00:04:27.280 --> 00:04:28.640
Najlepszą praktyką jest jednak

00:04:28.640 --> 00:04:30.160
rozdzielenie ich według środowisk.

00:04:30.320 --> 00:04:32.320
Użyj osobnego magazynu dla programowania,

00:04:32.500 --> 00:04:33.400
testów i produkcji.

00:04:33.660 --> 00:04:35.840
Zapobiega to przypadkowemu użyciu produkcyjnego

00:04:35.840 --> 00:04:38.700
wpisu w środowisku deweloperskim i ogranicza zasięg szkód

00:04:38.700 --> 00:04:40.020
w razie włamania do magazynu.

00:04:40.200 --> 00:04:42.580
Jednak przechowywanie wpisów to tylko połowa sukcesu.

00:04:42.740 --> 00:04:44.700
Prawdziwe pytanie brzmi, kto ma do nich dostęp?

00:04:45.000 --> 00:04:46.400
Jak działa kontrola dostępu?

00:04:46.560 --> 00:04:48.580
Porozmawiajmy teraz o tym, kto uzyskuje dostęp.

00:04:48.760 --> 00:04:50.720
Key Vault oferuje dwa sposoby kontroli dostępu

00:04:50.720 --> 00:04:52.680
do zawartości i wybór metody ma duże znaczenie.

00:04:52.900 --> 00:04:54.680
Pierwszym modelem są starsze zasady dostępu

00:04:54.680 --> 00:04:55.780
Legacy Access Policies.

00:04:55.920 --> 00:04:56.680
To stary sposób.

00:04:56.960 --> 00:04:58.680
Tworzysz zasady bezpośrednio w magazynie

00:04:58.680 --> 00:05:00.840
i przypisujesz uprawnienia konkretnym użytkownikom

00:05:00.840 --> 00:05:02.460
lub grupom dla określonych typów danych,

00:05:02.460 --> 00:05:04.140
wpisów, kluczy lub certyfikatów.

00:05:04.280 --> 00:05:06.560
Problem polega na tym, że zasady te są ściśle powiązane

00:05:06.560 --> 00:05:07.560
z konkretnym magazynem.

00:05:07.740 --> 00:05:09.820
Jeśli masz wiele magazynów, musisz zarządzać zasadami

00:05:09.820 --> 00:05:10.820
dla każdego z nich osobno.

00:05:11.020 --> 00:05:12.040
Nie skaluje się to dobrze.

00:05:12.340 --> 00:05:14.320
Microsoft odradza obecnie ich stosowanie,

00:05:14.440 --> 00:05:16.340
ponieważ mają znane luki w zabezpieczeniach.

00:05:16.480 --> 00:05:18.880
Nie obsługują one zarządzania tożsamością uprzywilejowaną

00:05:18.880 --> 00:05:21.320
i mogą prowadzić do nieoczekiwanej eskalacji uprawnień.

00:05:21.520 --> 00:05:23.020
Drugim modelem jest Azure RBAC,

00:05:23.260 --> 00:05:24.880
czyli kontrola dostępu oparta na rolach.

00:05:25.000 --> 00:05:26.000
To nowoczesny sposób.

00:05:26.300 --> 00:05:27.780
Wykorzystuje tożsamości EntraID

00:05:27.780 --> 00:05:29.520
i jest spójny z zarządzaniem uprawnieniami

00:05:29.520 --> 00:05:30.740
w pozostałych usługach Azure.

00:05:30.940 --> 00:05:33.360
Jeśli wiesz, jak nadać komuś dostęp do konta magazynu

00:05:33.360 --> 00:05:34.380
lub maszyny wirtualnej,

00:05:34.500 --> 00:05:36.360
wiesz też, jak nadać mu dostęp do Key Vault.

00:05:36.540 --> 00:05:38.340
Ten sam system, te same wzorce.

00:05:38.560 --> 00:05:40.620
Oto złota zasada, najmniejsze uprawnienia.

00:05:40.900 --> 00:05:43.320
Dawaj tylko minimalny dostęp, którego ktoś potrzebuje,

00:05:43.440 --> 00:05:43.900
nic więcej.

00:05:44.140 --> 00:05:45.780
Jeśli ktoś musi tylko odczytywać wpisy,

00:05:45.780 --> 00:05:47.880
nie dawaj mu uprawnień do ich tworzenia ani usuwania.

00:05:48.060 --> 00:05:50.020
Jeśli ktoś musi tylko zarządzać certyfikatami,

00:05:50.120 --> 00:05:51.320
nie dawaj mu dostępu do kluczy.

00:05:51.480 --> 00:05:52.660
Omówię teraz kluczowe role.

00:05:52.880 --> 00:05:54.620
Masz role czytelnika Key Vault, Key Vault Reader.

00:05:54.800 --> 00:05:56.040
Pozwala ona na wyświetlenie listy wpisów,

00:05:56.040 --> 00:05:57.020
ale nie na odczyt ich wartości.

00:05:57.180 --> 00:05:58.920
Użytkownik wpisów Key Vault, Key Vault Secrets User.

00:05:59.120 --> 00:06:01.060
Pozwala ona na rzeczywisty odczyt wartości wpisów tajnych.

00:06:01.240 --> 00:06:03.140
Oraz oficer wpisów Key Vault, Key Vault Secrets Officer.

00:06:03.340 --> 00:06:04.800
Pozwala ona na tworzenie, aktualizację

00:06:04.800 --> 00:06:05.920
i usuwanie wpisów tajnych.

00:06:06.140 --> 00:06:07.060
Zauważ ten schemat.

00:06:07.280 --> 00:06:09.180
Każda rola dotyczy danych wewnątrz magazynu,

00:06:09.260 --> 00:06:10.280
a nie samego magazynu.

00:06:10.480 --> 00:06:11.980
Zestawmy to teraz z ogólnymi rolami

00:06:11.980 --> 00:06:13.780
właściciela, współtwórcy i czytelnika.

00:06:14.020 --> 00:06:15.540
Dotyczą one skarbca jako zasobu,

00:06:15.600 --> 00:06:16.700
a nie danych w nim zawartych.

00:06:16.940 --> 00:06:18.780
Właściciel może usunąć cały skarbiec.

00:06:19.000 --> 00:06:21.180
Współtwórca może modyfikować ustawienia skarbca.

00:06:21.380 --> 00:06:22.820
Jednak żadna z tych ról sama w sobie

00:06:22.820 --> 00:06:25.140
nie daje dostępu do znajdujących się wewnątrz sekretów.

00:06:25.240 --> 00:06:26.620
To oddzielna warstwa uprawnień

00:06:26.620 --> 00:06:27.700
i to jest kluczowy punkt.

00:06:27.900 --> 00:06:29.780
Kontrola dostępu to system warstwowy.

00:06:29.960 --> 00:06:31.620
Potrzebujesz dostępu do samego skarbca

00:06:31.620 --> 00:06:32.440
to pierwsza warstwa

00:06:32.440 --> 00:06:34.240
oraz dostępu do danych wewnątrz skarbca

00:06:34.240 --> 00:06:35.020
to druga warstwa.

00:06:35.200 --> 00:06:36.980
Oba muszą zostać przyznane oddzielnie.

00:06:37.200 --> 00:06:38.400
Większość początkujących myśli

00:06:38.400 --> 00:06:39.400
tylko o pierwszej warstwie,

00:06:39.520 --> 00:06:40.320
zapominając o drugiej.

00:06:40.540 --> 00:06:41.820
Od tego zaczynają się kłopoty.

00:06:42.020 --> 00:06:43.740
To błąd numer jeden w zabezpieczeniach.

00:06:43.740 --> 00:06:44.940
Rzecz w tym, że większość ludzi

00:06:44.940 --> 00:06:46.180
patrzy na rolę współtwórca Kivolt

00:06:46.180 --> 00:06:47.260
i uważa ją za bezpieczną.

00:06:47.480 --> 00:06:48.460
Widzą słowo współtwórca

00:06:48.460 --> 00:06:49.680
i zakładają, że mogą zarządzać

00:06:49.680 --> 00:06:50.480
ustawieniami skarbca,

00:06:50.580 --> 00:06:51.920
ale nie ruszać zawartych w nim sekretów.

00:06:52.100 --> 00:06:53.600
Oryginalna dokumentacja Microsoftu

00:06:53.600 --> 00:06:54.700
głosiła dokładnie to samo.

00:06:54.860 --> 00:06:56.040
Ta rola nie pozwala na dostęp

00:06:56.040 --> 00:06:57.920
do sekretów, kluczy ani certyfikatów.

00:06:58.060 --> 00:06:58.760
Z wyjątkiem tego,

00:06:58.880 --> 00:07:00.060
że nie do końca jest to prawda.

00:07:00.320 --> 00:07:02.040
Użytkownik z rolą współtwórca Kivolt

00:07:02.040 --> 00:07:04.200
może modyfikować zasady dostępu do skarbca.

00:07:04.380 --> 00:07:05.800
A jeśli ten skarbiec wciąż używa

00:07:05.800 --> 00:07:06.840
starszych zasad dostępu,

00:07:06.900 --> 00:07:07.960
co jest częstą praktyką,

00:07:07.960 --> 00:07:09.340
mogą oni po prostu przyznać sobie

00:07:09.340 --> 00:07:10.340
pełny dostęp do odczytu

00:07:10.340 --> 00:07:11.400
każdego sekretu, klucza

00:07:11.400 --> 00:07:12.420
i certyfikatu w środku.

00:07:12.600 --> 00:07:13.880
Nie potrzeba żadnego specjalnego

00:07:13.880 --> 00:07:15.120
eksploita ani łatania luk.

00:07:15.240 --> 00:07:16.800
Tak po prostu działają te uprawnienia.

00:07:17.060 --> 00:07:18.200
Badacze bezpieczeństwa z Datadog

00:07:18.200 --> 00:07:20.120
udowodnili to w 2024 roku.

00:07:20.360 --> 00:07:21.500
Wykazali, że współtwórca

00:07:21.500 --> 00:07:23.000
może uzyskać pełny dostęp do danych

00:07:23.000 --> 00:07:24.320
w każdym skarbcu korzystającym

00:07:24.320 --> 00:07:25.460
ze starszych zasad dostępu.

00:07:25.660 --> 00:07:27.640
Reakcja Microsoftu była interesująca.

00:07:27.880 --> 00:07:29.180
Stwierdzili, że nie jest to luka,

00:07:29.280 --> 00:07:30.760
ponieważ współtwórcy mają zarządzać

00:07:30.760 --> 00:07:31.620
zasadami dostępu,

00:07:31.700 --> 00:07:33.040
ale zaktualizowali dokumentację,

00:07:33.140 --> 00:07:33.940
by wyraźnie ostrzec,

00:07:33.940 --> 00:07:35.260
że rola ta może sama przyznać

00:07:35.260 --> 00:07:36.600
sobie dostęp do płaszczyzny danych.

00:07:36.820 --> 00:07:38.500
Nie jest to więc błąd w samym Key Vault,

00:07:38.660 --> 00:07:39.920
lecz pułapka konfiguracyjna.

00:07:40.120 --> 00:07:41.800
Wpada w nią nawet doświadczone zespoły,

00:07:41.900 --> 00:07:43.280
bo nazwa roli brzmi niegroźnie.

00:07:43.640 --> 00:07:44.940
Współtwórca nie brzmi jak ktoś,

00:07:45.060 --> 00:07:46.360
kto może odczytać twoje hasła

00:07:46.360 --> 00:07:47.000
do baz danych,

00:07:47.160 --> 00:07:48.000
ale w praktyce może.

00:07:48.180 --> 00:07:49.220
Pomyśl o ryzyku.

00:07:49.440 --> 00:07:51.100
Jeśli atakujący przejmie konto

00:07:51.100 --> 00:07:53.040
z rolą współtwórcy w twoim Key Vault,

00:07:53.200 --> 00:07:54.820
nie musi włamywać się do skarbca.

00:07:55.140 --> 00:07:56.480
Nie musi łamać szyfrowania.

00:07:56.760 --> 00:07:58.900
Wystarczy, że zmodyfikuje zasady dostępu,

00:07:59.000 --> 00:08:00.260
przyzna sobie prawo do odczytu

00:08:00.260 --> 00:08:02.560
i po cichu wykradnie każdy przechowywany sekret,

00:08:02.680 --> 00:08:03.500
ciągi połączeń,

00:08:03.600 --> 00:08:04.120
klucze API,

00:08:04.300 --> 00:08:05.280
certyfikaty, wszystko.

00:08:05.520 --> 00:08:06.980
A ponieważ zmiany zasad dostępu

00:08:06.980 --> 00:08:08.660
to normalna czynność administracyjna,

00:08:08.780 --> 00:08:10.320
może to nie wywołać żadnych alertów.

00:08:10.500 --> 00:08:11.420
Jak więc to naprawić?

00:08:11.580 --> 00:08:11.940
Po pierwsze,

00:08:12.080 --> 00:08:12.940
używaj Azure RBAC

00:08:12.940 --> 00:08:14.100
do dostępu do płaszczyzny danych

00:08:14.100 --> 00:08:15.340
zamiast starszych zasad dostępu.

00:08:15.500 --> 00:08:17.240
RBAC oddziela zarządzanie skarbcem

00:08:17.240 --> 00:08:18.460
od znajdujących się w nim danych.

00:08:18.660 --> 00:08:19.000
Po drugie,

00:08:19.120 --> 00:08:20.780
nigdy nie nadawaj roli współautora Key Vault

00:08:20.780 --> 00:08:22.480
nikomu, kto jej absolutnie nie potrzebuje.

00:08:22.640 --> 00:08:23.020
Po trzecie,

00:08:23.020 --> 00:08:24.740
jeśli masz już użytkowników z tą rolą,

00:08:24.820 --> 00:08:26.220
przeprowadź ich audyt jeszcze dzisiaj.

00:08:30.260 --> 00:08:31.020
dostępu Key Vault

00:08:31.020 --> 00:08:32.200
istnieje drugi błąd,

00:08:32.300 --> 00:08:33.220
który potęguje pierwszy,

00:08:33.360 --> 00:08:34.680
przechowywanie wszystkich sekretów

00:08:34.680 --> 00:08:35.560
w jednym magazynie.

00:08:35.760 --> 00:08:36.820
Jeśli masz jeden magazyn

00:08:36.820 --> 00:08:38.000
do wszystkiego programowania,

00:08:38.160 --> 00:08:39.460
testów, wdrożeń, produkcji

00:08:39.460 --> 00:08:40.500
i wszystkich aplikacji,

00:08:40.600 --> 00:08:42.160
a magazyn ten zostanie przejęty,

00:08:42.280 --> 00:08:43.480
wszystko zostaje ujawnione.

00:08:43.660 --> 00:08:45.020
To pojedynczy punkt awarii.

00:08:45.220 --> 00:08:46.300
Za chwilę porozmawiamy więcej

00:08:46.300 --> 00:08:47.520
o strategii wielu magazynów,

00:08:47.640 --> 00:08:48.620
ale zasada jest prosta.

00:08:48.820 --> 00:08:49.840
Nie wkładaj wszystkich jajek

00:08:49.840 --> 00:08:50.560
do jednego koszyka,

00:08:50.720 --> 00:08:51.640
zwłaszcza gdy w tym koszyku

00:08:51.640 --> 00:08:52.440
znajdują się klucze

00:08:52.440 --> 00:08:53.740
do całej twojej infrastruktury.

00:08:53.940 --> 00:08:55.000
Tożsamość zarządzana,

00:08:55.140 --> 00:08:55.740
złoty standard.

00:08:55.740 --> 00:08:57.160
Jak więc zrobić to dobrze?

00:08:57.420 --> 00:08:58.400
Porozmawiajmy o najlepszym

00:08:58.400 --> 00:08:59.680
sposobie dostępu do Key Vault.

00:08:59.880 --> 00:09:01.200
Istnieje fundamentalny problem.

00:09:01.440 --> 00:09:02.820
Aby uzyskać poświadczenia z Key Vault,

00:09:02.980 --> 00:09:04.320
aplikacja musi się uwierzytelnić,

00:09:04.420 --> 00:09:05.220
ale do uwierzytelnienia

00:09:05.220 --> 00:09:06.240
potrzebuje poświadczeń.

00:09:06.400 --> 00:09:07.500
Gdzie przechowywać poświadczenia,

00:09:07.640 --> 00:09:08.580
których aplikacja używa

00:09:08.580 --> 00:09:09.860
do zdobycia innych poświadczeń?

00:09:09.960 --> 00:09:11.220
To problem jajka i kury.

00:09:11.480 --> 00:09:12.600
Starym rozwiązaniem była

00:09:12.600 --> 00:09:14.260
jednostka usługi z kluczem tajnym,

00:09:14.400 --> 00:09:15.960
ale ten klucz musi gdzieś istnieć

00:09:15.960 --> 00:09:17.360
może w pliku konfiguracyjnym,

00:09:17.480 --> 00:09:18.560
zmiennych środowiskowych

00:09:18.560 --> 00:09:19.620
lub potoku wdrażania.

00:09:19.820 --> 00:09:21.380
I wracasz do tego samego problemu.

00:09:21.380 --> 00:09:22.680
Po prostu przeniosłeś sekret

00:09:22.680 --> 00:09:23.440
w inne miejsce.

00:09:23.700 --> 00:09:24.580
Tożsamość zarządzana

00:09:24.580 --> 00:09:25.680
rozwiązuje to całkowicie.

00:09:25.880 --> 00:09:26.680
Oto jak to działa.

00:09:26.940 --> 00:09:28.420
Gdy włączasz tożsamość zarządzaną

00:09:28.420 --> 00:09:29.140
w zasobie Azure,

00:09:29.280 --> 00:09:30.580
na przykład w aplikacji webowej,

00:09:30.700 --> 00:09:32.100
funkcji lub maszynie wirtualnej,

00:09:32.220 --> 00:09:33.920
Azure automatycznie tworzy tożsamość

00:09:33.920 --> 00:09:35.200
dla tego zasobu w EntraID.

00:09:35.400 --> 00:09:36.800
Ta tożsamość jest w całości

00:09:36.800 --> 00:09:37.880
zarządzana przez Azure.

00:09:38.140 --> 00:09:39.460
Żadnych poświadczeń do tworzenia,

00:09:39.600 --> 00:09:40.800
żadnych sekretów do rotowania,

00:09:40.960 --> 00:09:41.780
nic do przechowywania.

00:09:42.020 --> 00:09:43.640
Zasób po prostu posiada tożsamość,

00:09:43.700 --> 00:09:44.620
o której Azure wie.

00:09:44.840 --> 00:09:45.840
Istnieją dwa typy.

00:09:46.020 --> 00:09:46.900
Tożsamość zarządzana

00:09:46.900 --> 00:09:47.900
przypisana przez system

00:09:47.900 --> 00:09:48.920
jest powiązana z jednym

00:09:48.920 --> 00:09:49.780
konkretnym zasobem.

00:09:49.980 --> 00:09:51.040
Jeśli usuniesz zasób,

00:09:51.160 --> 00:09:52.400
tożsamość również zniknie.

00:09:52.640 --> 00:09:53.700
Dzielą one cykl życia,

00:09:53.880 --> 00:09:55.180
co upraszcza administrację.

00:09:55.380 --> 00:09:56.300
Tożsamość zarządzana

00:09:56.300 --> 00:09:57.520
przypisana przez użytkownika

00:09:57.520 --> 00:09:58.680
to samodzielna tożsamość,

00:09:58.800 --> 00:09:59.720
którą możesz przypisać

00:09:59.720 --> 00:10:00.500
do wielu zasobów.

00:10:00.660 --> 00:10:01.600
Nie dzieli ona cyklu życia

00:10:01.600 --> 00:10:02.220
z żadnym z nich,

00:10:02.320 --> 00:10:03.140
więc jest przydatna,

00:10:03.260 --> 00:10:04.300
gdy potrzebujesz tej samej

00:10:04.300 --> 00:10:05.640
tożsamości dla kilku usług.

00:10:05.800 --> 00:10:07.280
Oto jak wygląda to w praktyce.

00:10:07.520 --> 00:10:08.520
Masz aplikację webową,

00:10:08.680 --> 00:10:09.460
która musi odczytać

00:10:09.460 --> 00:10:10.800
ciąg połączenia z bazą danych

00:10:10.800 --> 00:10:11.240
z Key Vault.

00:10:11.240 --> 00:10:12.720
Włączasz tożsamość zarządzaną

00:10:12.720 --> 00:10:13.720
przypisaną przez system

00:10:13.720 --> 00:10:14.820
dla tej aplikacji webowej.

00:10:15.020 --> 00:10:16.440
Następnie nadajesz tej tożsamości

00:10:16.440 --> 00:10:17.640
rolę użytkownika sekretów

00:10:17.640 --> 00:10:18.860
Key Vault w swoim magazynie.

00:10:19.000 --> 00:10:19.520
To wszystko.

00:10:19.800 --> 00:10:21.040
Żadnych ciągów połączeń w kodzie,

00:10:21.160 --> 00:10:21.960
żadnych kluczy tajnych

00:10:21.960 --> 00:10:23.040
w plikach konfiguracyjnych.

00:10:23.220 --> 00:10:24.060
Aplikacja internetowa

00:10:24.060 --> 00:10:25.320
uwierzytelnia się w usłudze Key Vault

00:10:25.320 --> 00:10:27.020
za pomocą swojej tożsamości zarządzanej,

00:10:27.080 --> 00:10:27.840
a Azure zajmuje się

00:10:27.840 --> 00:10:29.020
całym zarządzaniem poświadczeniami.

00:10:29.240 --> 00:10:30.120
Jest to rozwiązanie

00:10:30.120 --> 00:10:31.280
najbliższe uwierzytelnianiu

00:10:31.280 --> 00:10:31.920
bez poświadczeń

00:10:31.920 --> 00:10:32.780
w środowisku Azure.

00:10:32.780 --> 00:10:34.600
To przełom w dziedzinie bezpieczeństwa,

00:10:34.720 --> 00:10:35.540
ponieważ eliminuje

00:10:35.540 --> 00:10:36.900
najczęstszy wektor ataku

00:10:36.900 --> 00:10:38.040
kradzież poświadczeń.

00:10:38.220 --> 00:10:39.400
Jeśli nie ma poświadczeń

00:10:39.400 --> 00:10:40.020
do ukradzienia,

00:10:40.160 --> 00:10:41.780
atakujący nie ma czego przejąć.

00:10:41.880 --> 00:10:43.420
Podam przykład z życia wzięty.

00:10:43.660 --> 00:10:45.380
Wyobraźmy sobie potok danych w Synaps,

00:10:45.520 --> 00:10:46.680
który musi uzyskać dostęp

00:10:46.680 --> 00:10:47.640
do konta magazynu.

00:10:47.800 --> 00:10:49.000
Dawniej przechowywałoby się

00:10:49.000 --> 00:10:50.020
klucz konta magazynu

00:10:50.020 --> 00:10:51.060
w konfiguracji potoku.

00:10:51.320 --> 00:10:52.460
Jeśli ktoś uzyskał dostęp

00:10:52.460 --> 00:10:53.140
do tego potoku,

00:10:53.240 --> 00:10:54.120
miał dostęp do klucza.

00:10:54.360 --> 00:10:55.540
Dzięki tożsamości zarządzanej

00:10:55.540 --> 00:10:56.420
obszar roboczy Synaps

00:10:56.420 --> 00:10:57.620
posiada własną tożsamość.

00:10:57.760 --> 00:10:58.920
Tożsamości tej przyznaje się

00:10:58.920 --> 00:10:59.740
dostęp do Key Vault,

00:10:59.920 --> 00:11:00.760
gdzie przechowywany jest

00:11:00.760 --> 00:11:01.820
klucz konta magazynu.

00:11:01.940 --> 00:11:02.840
Potok pobiera klucz

00:11:02.840 --> 00:11:03.680
w czasie wykonywania,

00:11:03.840 --> 00:11:05.000
używa go i nigdy nigdzie

00:11:05.000 --> 00:11:05.780
go nie zapisuje.

00:11:06.040 --> 00:11:06.900
Brak kluczy w kodzie,

00:11:07.060 --> 00:11:08.800
brak sekretów w konfiguracji potoku.

00:11:09.060 --> 00:11:09.920
Gdy połączysz tożsamość

00:11:09.920 --> 00:11:10.800
zarządzaną z RBAC

00:11:10.800 --> 00:11:12.080
i zasadą najmniejszych uprawnień,

00:11:12.180 --> 00:11:13.160
zyskasz bezpieczny fundament

00:11:13.160 --> 00:11:14.380
dla każdego obciążenia w Azure.

00:11:14.580 --> 00:11:16.040
Twoje aplikacje uwierzytelniają się

00:11:16.040 --> 00:11:17.020
bez użycia poświadczeń.

00:11:17.140 --> 00:11:18.160
Uzyskują dostęp tylko do tego,

00:11:18.260 --> 00:11:18.720
czego potrzebują,

00:11:18.800 --> 00:11:19.860
a każde użycie jest rejestrowane

00:11:19.860 --> 00:11:20.760
i możliwe do skontrolowania.

00:11:20.760 --> 00:11:22.440
To wzorzec zalecany przez Microsoft

00:11:22.440 --> 00:11:23.740
w niemal każdym scenariuszu.

00:11:23.900 --> 00:11:24.800
Gdy zaczniesz go używać,

00:11:24.900 --> 00:11:25.760
będziesz się zastanawiać,

00:11:25.820 --> 00:11:27.320
dlaczego kiedykolwiek robiłeś to inaczej.

00:11:27.500 --> 00:11:29.200
Koszty i strategia wielu magazynów.

00:11:29.520 --> 00:11:30.780
Porozmawiajmy więc o kosztach.

00:11:30.940 --> 00:11:31.540
W tym miejscu

00:11:31.540 --> 00:11:32.860
większość osób jest zaskoczona.

00:11:33.100 --> 00:11:34.740
Ile tak naprawdę kosztuje Azure Key Vault?

00:11:34.980 --> 00:11:36.180
Model cenowy jest prosty.

00:11:36.340 --> 00:11:37.300
Brak opłaty za przechowywanie

00:11:37.300 --> 00:11:38.140
poszczególnych sekretów.

00:11:38.280 --> 00:11:39.180
Nie płacisz za każde hasło

00:11:39.180 --> 00:11:40.380
czy klucz API, które przechowujesz.

00:11:40.540 --> 00:11:41.860
Płacisz natomiast za operację.

00:11:42.060 --> 00:11:42.980
W warstwie standardowej

00:11:42.980 --> 00:11:43.780
to około 3 centy

00:11:43.780 --> 00:11:45.140
za każde 10 tysięcy operacji.

00:11:45.140 --> 00:11:46.440
Wywołanie pobrania sekretu

00:11:46.440 --> 00:11:47.600
liczy się jako jedna operacja.

00:11:47.760 --> 00:11:48.960
Podobnie jak tworzenie sekretu

00:11:48.960 --> 00:11:50.480
czy wyświetlanie zawartości magazynu.

00:11:50.660 --> 00:11:52.220
Dla typowej małej lub średniej aplikacji

00:11:52.220 --> 00:11:53.840
sumuje się to do kilku centów miesięcznie.

00:11:54.080 --> 00:11:55.300
Dosłownie kilku centów.

00:11:55.440 --> 00:11:57.320
Porównaj to z AWS Secrets Manager.

00:11:57.580 --> 00:11:59.400
Pobierają 40 centów za sekret miesięcznie

00:11:59.400 --> 00:12:00.240
za samo przechowywanie

00:12:00.240 --> 00:12:01.840
plus dodatkowe opłaty za wywołania API.

00:12:02.060 --> 00:12:02.980
Jeśli masz 100 sekretów

00:12:02.980 --> 00:12:04.160
to 40 dolarów miesięcznie

00:12:04.160 --> 00:12:05.660
zanim jeszcze odczytasz choćby jeden z nich.

00:12:05.840 --> 00:12:07.160
W Azure Key Vault 100 sekretów

00:12:07.160 --> 00:12:08.140
przy umiarkowanym użyciu

00:12:08.140 --> 00:12:09.640
może kosztować Cię 15 centów.

00:12:09.640 --> 00:12:11.560
Różnica szybko rośnie wraz ze skalą.

00:12:11.760 --> 00:12:13.120
Istnieje również warstwa premium.

00:12:13.400 --> 00:12:14.820
Dodaje ona klucze oparte na HSM

00:12:14.820 --> 00:12:15.920
dla obciążeń wymagających

00:12:15.920 --> 00:12:17.700
najwyższego poziomu gwarancji kryptograficznej.

00:12:17.840 --> 00:12:19.360
Pomyśl o transakcjach finansowych,

00:12:19.500 --> 00:12:21.100
danych medycznych, systemach rządowych.

00:12:21.280 --> 00:12:22.580
Koszt operacji jest wyższy

00:12:22.580 --> 00:12:24.980
około 15 centów za 10 tysięcy operacji

00:12:24.980 --> 00:12:26.380
dla zaawansowanych typów kluczy

00:12:26.380 --> 00:12:28.300
plus miesięczna opłata za klucz HSM.

00:12:28.500 --> 00:12:29.740
Jednak dla większości aplikacji

00:12:29.740 --> 00:12:32.000
warstwa standardowa jest w zupełności wystarczająca.

00:12:32.200 --> 00:12:33.240
Oto zaskakujący koszt,

00:12:33.380 --> 00:12:34.820
który często bierze ludzi z zaskoczenia.

00:12:35.100 --> 00:12:36.640
W przypadku typowej aplikacji internetowej

00:12:36.640 --> 00:12:38.960
z kilkoma sekretami i kilkoma tysiącami operacji miesięcznie,

00:12:39.060 --> 00:12:40.240
kosztki volt to mniej niż dolar.

00:12:40.440 --> 00:12:41.320
Więcej wydasz na kawę,

00:12:41.420 --> 00:12:42.920
którą wypijesz podczas konfiguracji.

00:12:43.120 --> 00:12:44.220
Istnieje jednak strategia,

00:12:44.340 --> 00:12:45.540
która jest ważniejsza niż koszt.

00:12:45.700 --> 00:12:46.940
Liczba używanych magazynów.

00:12:47.100 --> 00:12:49.260
Rozsądnym podejściem jest strategia wielu magazynów.

00:12:49.420 --> 00:12:50.300
Używaj oddzielnych magazynów

00:12:50.300 --> 00:12:51.280
dla środowisk programistycznych,

00:12:51.360 --> 00:12:52.740
testowych, stagingowych i produkcyjnych.

00:12:52.940 --> 00:12:54.540
Zapobiega to najczęstszemu przypadkowi.

00:12:54.740 --> 00:12:55.920
Ktoś uruchamia skrypt testowy,

00:12:55.920 --> 00:12:57.680
który przypadkowo odczytuje bazę produkcyjną,

00:12:57.740 --> 00:12:59.700
ponieważ ciąg połączeniowy był w tym samym magazynie.

00:12:59.880 --> 00:13:01.220
Gdy środowiska są odseparowane,

00:13:01.380 --> 00:13:02.580
taki błąd staje się niemożliwy.

00:13:02.760 --> 00:13:03.960
Powinieneś również dokonać separacji

00:13:03.960 --> 00:13:05.840
według jednostek biznesowych lub obszarów zgodności.

00:13:06.080 --> 00:13:07.640
Jeśli obsługujesz dane kart płatniczych,

00:13:07.760 --> 00:13:09.380
umieść te sekrety w osobnym magazynie.

00:13:09.540 --> 00:13:11.380
Ogólne zadania biznesowe trafiają do innego,

00:13:11.480 --> 00:13:12.560
a dane medyczne do trzeciego.

00:13:12.760 --> 00:13:13.780
Nie chodzi o utrudnianie pracy,

00:13:13.900 --> 00:13:15.740
lecz o ograniczenie zasięgu ewentualnej awarii.

00:13:15.900 --> 00:13:17.580
Jeśli jeden magazyn zostanie skompromitowany,

00:13:17.580 --> 00:13:19.200
narażone będą tylko sekrety w nim zawarte.

00:13:19.400 --> 00:13:21.340
Reszta Twojej infrastruktury pozostaje bezpieczna.

00:13:21.500 --> 00:13:22.900
Oraz dwie wbudowane sieci bezpieczeństwa,

00:13:23.020 --> 00:13:23.900
które zawsze warto włączyć.

00:13:24.040 --> 00:13:25.680
Usuwanie nietrwałe Soft Delete oznacza,

00:13:25.800 --> 00:13:26.840
że jeśli ktoś usunie sekret,

00:13:26.920 --> 00:13:27.740
nie znika on na stałe.

00:13:27.900 --> 00:13:29.220
Przechodzi w stan odzyskiwalny

00:13:29.220 --> 00:13:31.660
na wybrany okres przechowywania do 90 dni.

00:13:31.880 --> 00:13:33.480
Ochrona przed czyszczeniem Perge Protection

00:13:33.480 --> 00:13:34.340
idzie o krok dalej.

00:13:34.620 --> 00:13:36.040
Nikt nie może trwale usunąć magazynu

00:13:36.040 --> 00:13:36.880
ani jego zawartości,

00:13:37.020 --> 00:13:38.360
dopóki okres przechowywania nie minie.

00:13:38.560 --> 00:13:40.520
Razem zapobiegają one przypadkowej utracie danych,

00:13:40.520 --> 00:13:42.280
która spędza sen z powiek zespołom do spraw.

00:13:42.800 --> 00:13:43.240
Bezpieczeństwa.

00:13:43.460 --> 00:13:44.480
Jak to wszystko się łączy?

00:13:44.660 --> 00:13:45.640
Epnijmy to wszystko razem

00:13:45.640 --> 00:13:47.240
i zobaczmy, jak elementy do siebie pasują.

00:13:47.440 --> 00:13:48.660
Key Vault nie jest wyspą.

00:13:48.820 --> 00:13:50.660
To centralny układ nerwowy dla sekretów

00:13:50.660 --> 00:13:51.920
w Twojej architekturze Azure.

00:13:52.200 --> 00:13:53.940
Gdy zrozumiesz, jak przepływa cały system,

00:13:54.080 --> 00:13:55.400
wszystko wskoczy na swoje miejsce.

00:13:55.680 --> 00:13:57.920
Oto co dzieje się, gdy aplikacja potrzebuje sekretu.

00:13:58.100 --> 00:13:59.180
Aplikacja wysyła żądanie

00:13:59.180 --> 00:14:01.000
przy użyciu swojej tożsamości zarządzanej.

00:14:01.100 --> 00:14:03.460
Ta tożsamość jest już zarejestrowana w EntraID.

00:14:03.700 --> 00:14:05.240
Azure utworzył ją automatycznie,

00:14:05.240 --> 00:14:07.560
gdy włączyłeś tożsamość zarządzaną dla zasobu.

00:14:07.680 --> 00:14:10.200
EntraID weryfikuje, czy tożsamość jest autentyczna,

00:14:10.280 --> 00:14:12.060
a następnie przekazuje żądanie do Key Vault.

00:14:12.240 --> 00:14:13.860
Key Vault sprawdza uprawnienia RBAC,

00:14:14.080 --> 00:14:15.000
które zostały przypisane.

00:14:15.000 --> 00:14:16.700
Jeśli tożsamość ma odpowiednią rolę,

00:14:16.780 --> 00:14:18.260
na przykład Key Vault Secrets User,

00:14:18.400 --> 00:14:19.460
sekret zostaje zwrócony.

00:14:19.620 --> 00:14:21.100
Wszystko to dzieje się w milisekundach.

00:14:21.260 --> 00:14:23.040
Aplikacja nigdy nie widzi danych uwierzytelniających.

00:14:23.240 --> 00:14:24.240
Nigdy nie przechowuje hasła.

00:14:24.420 --> 00:14:26.100
Po prostu otrzymuje wartość, której potrzebuje.

00:14:26.260 --> 00:14:28.660
Teraz pomyśl, jak wiele usług Azure może się z tym połączyć.

00:14:28.660 --> 00:14:32.640
App Service, Functions, AKS, Data Factory, Synapse, Logic Apps, DevOps Pipelines

00:14:32.640 --> 00:14:34.420
wszystkie wiedzą, jak komunikować się z Key Vault.

00:14:34.600 --> 00:14:36.500
Możesz skonfigurować aplikację internetową tak,

00:14:36.600 --> 00:14:39.160
aby odwoływała się do sekretu bezpośrednio w ustawieniach aplikacji.

00:14:39.400 --> 00:14:41.220
Możesz skonfigurować potok Data Factory tak,

00:14:41.220 --> 00:14:43.700
aby pobierał klucz konta magazynu z Key Vault w trakcie działania.

00:14:43.920 --> 00:14:45.700
Możesz skonfigurować klaster Kubernetes tak,

00:14:45.800 --> 00:14:48.340
aby pobierał sekrety za pomocą sterownika Key Vault CSI.

00:14:48.540 --> 00:14:50.260
Każda usługa integruje się w ten sam sposób,

00:14:50.400 --> 00:14:52.100
używając tego samego systemu tożsamości,

00:14:52.220 --> 00:14:54.640
tych samych ról RBAC i tego samego dziennika audytu.

00:14:54.640 --> 00:14:56.940
Wzorzec CI-CD jest szczególnie skuteczny.

00:14:57.100 --> 00:14:59.780
Twoje potoki pobierają sekrety z Key Vault w czasie wdrażania.

00:15:00.020 --> 00:15:01.780
Nigdy nie przechowują ich w zmiennych potoku

00:15:01.780 --> 00:15:03.140
ani w sekretach repozytorium.

00:15:03.320 --> 00:15:05.220
Jeśli musisz zmienić hasło do bazy danych,

00:15:05.380 --> 00:15:06.540
aktualizujesz je w Key Vault.

00:15:06.540 --> 00:15:09.800
Przy następnym uruchomieniu potok automatycznie pobierze nową wartość.

00:15:09.960 --> 00:15:12.640
Bez zmian w potoku, bez zmian w kodzie, bez ponownych wdrożeń.

00:15:12.760 --> 00:15:14.880
Oto element, dzięki któremu wszystko nabiera sensu.

00:15:15.040 --> 00:15:17.380
Gdy skonfigurujesz Key Vault z tożsamością zarządzaną i RBAC,

00:15:17.560 --> 00:15:19.460
całkowicie przestaniesz myśleć o zarządzaniu poświadczeniami.

00:15:19.460 --> 00:15:21.140
Twoje aplikacje po prostu działają.

00:15:21.380 --> 00:15:23.480
Sekrety są Rotowain, a nikt nawet tego nie zauważa.

00:15:23.680 --> 00:15:25.880
Certyfikaty odnawiają się bez nocnych sytuacji awaryjnych.

00:15:26.100 --> 00:15:27.580
System zajmuje się tym wszystkim w tle.

00:15:27.760 --> 00:15:29.840
To jest postawa bezpieczeństwa, która ma znaczenie.

00:15:30.080 --> 00:15:31.820
Tożsamość stanowi perymetr, a nie sieć.

00:15:31.820 --> 00:15:35.260
Nie ma znaczenia, czy ktoś znajduje się wewnątrz Twojej sieci wirtualnej, czy poza nią.

00:15:35.460 --> 00:15:38.560
Liczy się to, czy posiada prawidłową tożsamość z odpowiednimi uprawnieniami.

00:15:38.760 --> 00:15:40.640
Key Vault wymusza to w swojej konstrukcji.

00:15:40.860 --> 00:15:44.700
Każde żądanie dostępu przechodzi przez uwierzytelnianie EntraID i autoryzację RBAC,

00:15:44.900 --> 00:15:46.240
niezależnie od tego, skąd pochodzi.

00:15:46.440 --> 00:15:47.660
I wszystko jest rejestrowane.

00:15:47.860 --> 00:15:50.380
Każdy odczyt sekretu, każda operacja na kluczu, każde pobranie certyfikatu.

00:15:50.600 --> 00:15:52.440
Możesz zobaczyć, kto uzyskał dostęp do czego i kiedy.

00:15:52.680 --> 00:15:55.180
Jeśli coś wygląda podejrzanie, masz dane do przeprowadzenia dochodzenia.

00:15:55.180 --> 00:15:59.500
Jest to kluczowe dla zgodności reagowania na incydenty oraz po prostu wiedzy o tym, co dzieje się w Twoim środowisku.

00:15:59.680 --> 00:16:01.300
Na tym polega piękno tego rozwiązania.

00:16:01.460 --> 00:16:06.360
Key Vault, EntraID, RBAC i tożsamość zarządzana współpracują jako zintegrowane ramy bezpieczeństwa.

00:16:06.560 --> 00:16:08.260
Każdy element wzmacnia pozostałe.

00:16:08.420 --> 00:16:12.040
A gdy wszystko jest poprawnie skonfigurowane, otrzymujesz system zarządzania poświadczeniami,

00:16:12.180 --> 00:16:15.960
który jest bezpieczniejszy i łatwiejszy w obsłudze niż cokolwiek, co mógłbyś zbudować samodzielnie.

00:16:16.140 --> 00:16:17.120
Praktyczne wnioski.

00:16:17.300 --> 00:16:19.080
Co więc powinieneś zrobić już teraz?

00:16:19.260 --> 00:16:20.640
Przekujmy tę wiedzę w działanie.

00:16:20.840 --> 00:16:23.060
Oto rzeczy, którymi możesz zająć się w tym tygodniu.

00:16:25.180 --> 00:16:27.920
Key Vault w portalu przejdź do konfiguracji dostępu i sprawdź, co tam jest napisane.

00:16:28.080 --> 00:16:30.700
Jeśli widzisz zasady dostępu do magazynu, to jest to przestarzała metoda.

00:16:30.700 --> 00:16:33.720
Zamiast tego wybierz kontrolę dostępu opartą na rolach platformy Azure.

00:16:33.900 --> 00:16:35.000
Migracja jest prosta.

00:16:35.260 --> 00:16:39.920
Zmień model uprawnień i przypisz rolę RBAC tym samym osobom, które już miały zasady dostępu.

00:16:40.120 --> 00:16:40.820
Zrób to dzisiaj.

00:16:41.060 --> 00:16:44.880
Microsoft to zaleca, a badania, o których mówiliśmy, dokładnie pokazują dlaczego.

00:16:45.180 --> 00:16:48.060
Następnie sprawdź konta posiadające rolę współautora Key Vault.

00:16:48.260 --> 00:16:51.620
Otwórz kartę IAM w swoim magazynie i sprawdź, kto ma dostęp typu współautor.

00:16:51.760 --> 00:16:53.940
Każda osoba z tą rolą musi mieć ku temu dobry powód.

00:16:53.940 --> 00:16:55.580
Przez większość czasu tego nie robią.

00:16:55.820 --> 00:16:57.820
Zastąp rolę współtwórcy czymś bardziej szczegółowym.

00:16:57.820 --> 00:17:01.100
Jeśli ktoś musi tylko odczytywać sekrety, nadaj mu uprawnienia użytkownika wpisów Key Vault.

00:17:01.280 --> 00:17:04.240
Jeśli musi zarządzać sekretami, użyj roli administratora wpisów Key Vault.

00:17:04.440 --> 00:17:07.100
Celem jest całkowite zamknięcie tej ścieżki eskalacji uprawnień.

00:17:07.280 --> 00:17:09.260
Następnie skorzystaj z tożsamości zarządzanej.

00:17:09.420 --> 00:17:12.720
Każda usługa Azure wymagająca dostępu do Key Vault powinna z niej korzystać.

00:17:12.880 --> 00:17:18.940
Jeśli masz aplikację internetową, funkcję, data factory lub maszynę wirtualną korzystającą z jednostki usługi z kluczem tajnym,

00:17:19.080 --> 00:17:20.460
przejdź na tożsamość zarządzaną.

00:17:23.940 --> 00:17:27.220
Mówiliśmy. Azure zajmuje się zarządzaniem poświadczeniami za Ciebie w tle.

00:17:27.220 --> 00:17:31.020
Jeszcze jedno. Włącz usuwanie nietrwałe i ochronę przed przeczyszczaniem w każdym magazynie.

00:17:31.160 --> 00:17:35.100
Usuwanie nietrwałe jest domyślnie włączone dla nowych magazynów, ale ochrona przed przeczyszczaniem nie.

00:17:35.320 --> 00:17:40.300
Włącz ją. To ustawienie uniemożliwia trwałe usunięcie magazynu lub jego zawartości w okresie przechowywania.

00:17:40.520 --> 00:17:43.140
Uratowało już niejeden zespół przed katastrofalnym błędem.

00:17:43.300 --> 00:17:44.620
Oto Twoje zadanie do wykonania.

00:17:44.820 --> 00:17:47.140
Przyjrzyj się swojemu obecnemu podejściu do zarządzania sekretami.

00:17:47.140 --> 00:17:51.220
Znajdź jeden sekret, który wciąż znajduje się w pliku konfiguracyjnym zmiennej środowiskowej lub jest zakodowany w kodzie.

00:17:51.380 --> 00:17:52.920
Przenieś go do Key Vault w tym tygodniu.

00:17:53.040 --> 00:17:55.840
Tylko jeden. Gdy zobaczysz, jakie to proste, zechcesz przenieść resztę.

00:17:56.120 --> 00:17:57.680
Bezpieczeństwo to nie jednorazowa konfiguracja.

00:17:57.840 --> 00:17:58.740
To ciągła praktyka.

00:17:58.900 --> 00:18:01.480
Key Vault ułatwia tę praktykę, ale tylko wtedy, gdy używasz go poprawnie.

00:18:01.700 --> 00:18:02.840
Narzędzia są dostępne.

00:18:03.040 --> 00:18:04.120
Wzorce są sprawdzone.

00:18:04.340 --> 00:18:06.040
Teraz od Ciebie zależy, czy je wdrożysz.

00:18:06.240 --> 00:18:07.180
Taki jest ten system.

00:18:07.180 --> 00:18:11.220
Key Vault to Twój cyfrowy sejf, ale jest tak bezpieczny, jak kontrola dostępu, którą wokół niego ustanowisz.

00:18:11.420 --> 00:18:13.160
Zacznij od audytu, który właśnie opisałem.

00:18:13.380 --> 00:18:14.680
Sprawdź swój model uprawnień.

00:18:14.840 --> 00:18:18.060
Zweryfikuj przypisania współtwórców i przenieś jeden sekret do magazynu w tym tygodniu.

00:18:18.260 --> 00:18:23.900
Zasubskrybuj, aby otrzymywać więcej wskazówek o bezpieczeństwie w chmurze i udostępnij to komuś, kto wciąż przechowuje sekrety w plikach konfiguracyjnych.