https://thedotnetblog.com/pl/tags/managed-identity/Articles, tutorials and insights from the .NET community.Hugopl@thedotnetblog (The .NET Blog)@thedotnetblogThu, 16 Jul 2026 00:00:00 +0000https://thedotnetblog.com/pl/news/emiliano-montesdeoca/cosmosdb-role-assignment-without-secrets/Thu, 16 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/pl/news/emiliano-montesdeoca/cosmosdb-role-assignment-without-secrets/Jeśli twoja aplikacja Cosmos DB wciąż polega na kluczach, jesteś już w tyle pod względem bezpieczeństwa operacyjnego.<p>Oryginalne źródło: <a href="https://devblogs.microsoft.com/cosmosdb/which-azure-cosmos-db-role-does-my-app-need/">Which Azure Cosmos DB Role Does My App Need?</a></p> <p>Najważniejsza idea w tym wytycznym Cosmos DB to nie polecenie, ID roli czy sztuczka CLI. Jest architektoniczna: <strong>przestań traktować poświadczenia jako konfigurację aplikacji</strong> i zacznij traktować tożsamość jako stan wykonawczy.</p> <p>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&rsquo;u lub wyciekły log. Tożsamość zarządzana plus RBAC płaszczyzny danych usuwa tę klasę awarii prawie całkowicie.</p> <p>Praktycznym wyzwaniem jest zamieszanie między autoryzacją <strong>płaszczyzny sterowania</strong> a <strong>płaszczyzny danych</strong>. 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.</p> <h3 id="moja-stanowcza-rekomendacja-dla-zespołów-produkcyjnych">Moja stanowcza rekomendacja dla zespołów produkcyjnych</h3> <ul> <li><strong>Zacznij od Data Reader</strong> dla ścieżek odczytu i Data Contributor tylko tam, gdzie zapisy są naprawdę wymagane.</li> <li><strong>Nadaj szeroki zakres tylko wtedy</strong>, gdy masz jedną granicę aplikacji na konto.</li> <li><strong>Jeśli współdzielisz konto między usługami</strong>, zawęź zakres wcześnie do granic bazy danych lub kontenera, zamiast czekać na presję audytu.</li> </ul> <p>To jedna z tych decyzji, które <strong>procentują</strong>. Gdy podłączysz swoją aplikację .NET z <code>DefaultAzureCredential</code> 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.</p> <p>Artykuł sugeruje też coś, co dojrzałe zespoły powinny przyjąć: <strong>uprawnienia jako iteracyjny design</strong>, 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.</p> <p>Jeśli przyjmiesz tylko jedną rzecz z tego wpisu, niech to będzie: <strong>usuń sekrety najpierw, optymalizuj role potem</strong>. Zespoły, które odwracają tę kolejność, zwykle grzęzną w spotkaniach. Zespoły, które usuwają sekrety najpierw, zwykle dostarczają, a potem hartują.</p> <p>W 2026 roku <strong>bezsekretowy dostęp do danych to nie zaawansowany wzorzec</strong>. To minimalny odpowiedzialny standard dla poważnych systemów .NET na Azure.</p>