비밀 없는 Cosmos DB 접근이 새로운 기준입니다

Emiliano Montesdeoca — Thu, 16 Jul 2026 00:00:00 +0000

원문: Which Azure Cosmos DB Role Does My App Need?

이 Cosmos DB 가이드에서 가장 중요한 아이디어는 명령어, 역할 ID, CLI 트릭이 아닙니다. 아키텍처적입니다: 자격 증명을 앱 구성으로 취급하는 것을 중단하고 아이덴티티를 런타임 상태로 취급하기 시작하세요.

너무 많은 팀이 여전히 빠르게 느껴지기 때문에 연결 문자열을 사용하여 출시합니다. 빠른 것이 아닙니다. 연기된 위험입니다. 구성 파일의 모든 키는 성급한 커밋, 복사된 파이프라인 변수, 유출된 로그를 기다리는 사고가 됩니다. 관리 아이덴티티와 데이터 플레인 RBAC는 그 실패 클래스를 거의 완전히 제거합니다.

실용적인 과제는 제어 플레인과 데이터 플레인 권한 부여 간의 혼동입니다. 이것은 많은 강력한 팀이 며칠을 잃는 지점입니다. 리소스에 대한 Azure RBAC 역할이 자동으로 문서 접근을 부여하지 않으며, Cosmos 데이터 플레인 역할이 계정 관리를 부여하지 않습니다. 팀이 런북에서 그 분리를 명시적으로 문서화하지 않으면, 취약한 배포와 디버깅하기 어려운 403 에러가 계속 발생합니다.

프로덕션 팀을 위한 독단적 권장사항

읽기 경로에는 Data Reader로 시작하고, 쓰기가 실제로 필요한 경우에만 Data Contributor를 사용하세요.
계정당 단일 애플리케이션 경계가 있을 때만 광범위하게 범위를 지정하세요.
계정을 서비스 간에 공유하는 경우, 감사 압력을 기다리지 말고 데이터베이스 또는 컨테이너 경계로 일찍 범위를 좁히세요.

이것은 복리 효과가 있는 결정 중 하나입니다. .NET 앱을 DefaultAzureCredential과 엔드포인트 전용 구성으로 연결하면, 로컬, CI, 스테이징, 프로덕트 등 모든 환경이 더 깔끔해집니다. 또한 사고 대응이 빨라지는데, 알 수 없는 키를 추적하는 대신 역할 할당을 통해 권한을 추론할 수 있기 때문입니다.

이 글은 또한 성숙한 팀이 받아들여야 할 것을 암시합니다: 권한은 일회성 설정이 아닌 반복적 설계입니다. 전달하기에 충분할 만큼 넓게 시작한 다음, 텔레메트리와 접근 검토로 점진적으로 좁힐 수 있습니다. 최소 권한은 철학적 종착점이 아니라 전달 습관입니다.

이 포스트에서 한 가지만 채택한다면, 이것으로 하세요: 비밀을 먼저 제거하고, 역할은 다음에 최적화하세요. 순서를 바꾸는 팀은 보통 회의에서 정체됩니다. 비밀을 먼저 제거하는 팀은 보통 출시한 다음 강화합니다.

2026년에 비밀 없는 데이터 접근은 고급 패턴이 아닙니다. Azure의 진지한 .NET 시스템을 위한 최소한의 책임 있는 기준입니다.

Cloud-Security | The .NET Blog

비밀 없는 Cosmos DB 접근이 새로운 기준입니다

프로덕션 팀을 위한 독단적 권장사항