Azure blob 저장 및 보안 우수 사례

Question

Azure 저장소를 탐색 할 때 저장소 컨테이너에 대한 액세스가 공유 키를 통해 이루어 졌다는 것을 알았습니다. 개발자가 구축중인 애플리케이션에이 키를 사용하고 회사를 떠나서 스토리지 계정에 로그인하고 원하는 것을 삭제할 수 있다면 걱정할 필요가 없습니다. 이 문제를 해결하려면 계정의 보조 키를 다시 생성해야하지만 그런 다음 해당 키를 사용하는 모든 응용 프로그램의 모든 키를 변경해야합니다.

환경 (개발, 테스트, 스테이징, 프로덕션)별로 응용 프로그램 당 전체 스토리지 계정을 갖는 것이 가장 좋습니다. 가상 네트워크 뒤에서 저장소 계정을 보호 할 수 있습니까? 응용 프로그램별로 컨테이너의 서명을 사용해야합니까?

누구나 비슷한 경험을하고 있으며이를 처리하기위한 좋은 패턴을 발견 했습니까?

Answer 1

나는 조금 다른 시나리오가 - 외부 응용 프로그램을하지만, 문제는 동일합니다 - 데이터 액세스 보안

내가 컨테이너에 대한 액세스 권한을 부여 공유 액세스 서명 (SAS)를 사용합니다.

시나리오에서 컨테이너의 응용 프로그램마다 공유 액세스 정책을 만들고 만료 시간이 긴이 저장 액세스 정책을 사용하여 SAS를 생성 할 수 있습니다. 컨테이너에서 공유 액세스 정책을 제거하면 언제든지 해지 할 수 있습니다. 그래서 시나리오에서는 현재 SAS를 취소하고 개발자가 떠날 때 새 SAS를 생성 할 수 있습니다. 여러 컨테이너에 대해 단일 SAS를 생성 할 수 없으므로 응용 프로그램에서 여러 컨테이너를 사용하는 경우 여러 SAS를 생성해야합니다.

사용법, 개발자의 관점에서 동일하게 유지 : 당신은 CloudStorageAccount 또는 CloudBlobClient 그래서 거의 일정한 액세스 키처럼 만들 SAS 토큰을 사용할 수 있습니다.

오랫동안 SAS 생성 및 갱신을 담당하는 하나의 내부 서비스 (내부 API)를 만드는 것이 좋습니다. 이렇게하면 완전히 자동화 된 시스템을 가질 수 있으며 액세스 키는이 주 서비스에만 공개됩니다. 그런 다음 가상 네트워크, 인증서, 인증 등을 사용하여이 서비스에 대한 액세스를 제한 할 수 있습니다. 그리고 뭔가 잘못되면 (개발자가 서비스를 남긴 사람 :-)) 액세스 키를 다시 생성하고 변경할 수 있지만 이번에는 한 곳에서만 수행 할 수 있습니다.

몇 가지 : 응용 프로그램 (및/또는 환경) 당

• 저장 계정은 좋은 전략이지만 한계를 인식해야 - 가입 당 최대 100 개 저장 차지한다.
• 는, 당신은 내가 주관적/의견 답변으로받지 않습니다 하나의 컨테이너

Answer 2

에 최대 5 개 공유 액세스 정책을 가질 수있는 가상 네트워크

로 저장 계정에 대한 액세스를 제한 할 수있는 옵션이 없지만 객관적인 관점에서 : 개발자가 스토리지 계정 키를 가지고 있다면 저장소 계정에 대한 전체 액세스 권한을 갖습니다. 그리고 회사를 그만두고 열쇠 사본을 보관한다면? 이를 차단하는 유일한 방법은 키를 재생성하는 것입니다.

다른 저장소 계정으로 앱을 분리하면 도움이된다고 가정 할 수 있습니다. 그러나 개발자는 구독에 액세스 할 수있는 경우 해당 구독의 모든 단일 저장소 계정에 대한 키에 액세스 할 수 있습니다.

키 재생성을 생각할 때 키 자체를 알고있는 앱의 전체 표면적을 생각해보십시오. 스토리지 조작 만이 서버 측 작업 인 경우 키 변경의 영향은 최소화됩니다 (각 배포에서 작은 응용 프로그램 변경, 사용하는 스토리지 탐색 도구 업데이트와 함께). 직접 스토리지 액세스를 위해 데스크탑/모바일 애플리케이션에 키를 삽입 한 경우 업데이트 된 클라이언트를 푸시해야하는 데 더 큰 문제가 있지만 어쨌든 보안 문제가 발생했습니다.