Oryginalne źródło: Which Azure Cosmos DB Role Does My App Need?
Najważniejsza idea w tym wytycznym Cosmos DB to nie polecenie, ID roli czy sztuczka CLI. Jest architektoniczna: przestań traktować poświadczenia jako konfigurację aplikacji i zacznij traktować tożsamość jako stan wykonawczy.
Zbyt wiele zespołów wciąż wysyła aplikacje z ciągami połączeń, bo wydaje się to szybkie. To nie jest szybkie. To odroczone ryzyko. Każdy klucz w pliku konfiguracyjnym staje się incydentem czekającym na pośpieszny commit, skopiowaną zmienną pipeline’u lub wyciekły log. Tożsamość zarządzana plus RBAC płaszczyzny danych usuwa tę klasę awarii prawie całkowicie.
Praktycznym wyzwaniem jest zamieszanie między autoryzacją płaszczyzny sterowania a płaszczyzny danych. To tutaj wiele w innych aspektach silnych zespołów traci dni. Role RBAC Azure na zasobach nie przyznają automatycznie dostępu do dokumentów, a role płaszczyzny danych Cosmos DB nie przyznają administracji kontem. Jeśli twój zespół nie udokumentuje wyraźnie tego rozdzielenia w swoich runbookach, będziesz dostawać kruche wdrożenia i trudne do debugowania błędy 403.
Moja stanowcza rekomendacja dla zespołów produkcyjnych
- Zacznij od Data Reader dla ścieżek odczytu i Data Contributor tylko tam, gdzie zapisy są naprawdę wymagane.
- Nadaj szeroki zakres tylko wtedy, gdy masz jedną granicę aplikacji na konto.
- Jeśli współdzielisz konto między usługami, zawęź zakres wcześnie do granic bazy danych lub kontenera, zamiast czekać na presję audytu.
To jedna z tych decyzji, które procentują. Gdy podłączysz swoją aplikację .NET z DefaultAzureCredential i konfiguracją tylko z endpointem, każde środowisko staje się czystsze: lokalne, CI, staging i prod. Przyspieszasz też reakcję na incydenty, ponieważ możesz wnioskować o uprawnieniach przez przypisania ról, zamiast polować na tajemnicze klucze.
Artykuł sugeruje też coś, co dojrzałe zespoły powinny przyjąć: uprawnienia jako iteracyjny design, a nie jednorazowa konfiguracja. Możesz zacząć wystarczająco szeroko, by dostarczyć, a następnie zmniejszać zakres z telemetrią i przeglądami dostępu. Najmniejsze uprawnienia to nie filozoficzny punkt końcowy; to nawyk dostarczania.
Jeśli przyjmiesz tylko jedną rzecz z tego wpisu, niech to będzie: usuń sekrety najpierw, optymalizuj role potem. Zespoły, które odwracają tę kolejność, zwykle grzęzną w spotkaniach. Zespoły, które usuwają sekrety najpierw, zwykle dostarczają, a potem hartują.
W 2026 roku bezsekretowy dostęp do danych to nie zaawansowany wzorzec. To minimalny odpowiedzialny standard dla poważnych systemów .NET na Azure.
