공유 액세스 서명을 사용하여 Event Hubs 리소스에 대한 액세스 권한 부여

SAS(공유 액세스 서명)는 Event Hubs 네임스페이스의 리소스에 대한 제한된 액세스 권한을 부여하는 위임된 권한을 제공할 수 있습니다. SAS는 권한 부여 규칙에 따라 Event Hubs 리소스에 대한 액세스를 보호합니다. 이러한 규칙은 네임스페이스 또는 이벤트 허브에서 구성됩니다. 이 문서에서는 SAS 모델에 대해 간략하게 설명하고 SAS 모범 사례를 검토합니다.

공유 액세스 서명이란?

SAS(공유 액세스 서명)는 권한 부여 규칙에 따라 Event Hubs 리소스에 대한 위임된 액세스를 제공합니다. 권한 부여 규칙에는 특정 권한과 연결된 이름이 있으며 암호화 키 쌍을 전달합니다. Event Hubs 클라이언트 또는 사용자 고유의 코드를 통해 규칙 이름 및 키를 사용하여 SAS 토큰을 생성합니다. 그런 다음 클라이언트는 토큰을 Event Hubs에 전달하여 요청된 작업에 대한 권한 부여를 증명할 수 있습니다.

SAS는 단순 토큰을 사용하는 클레임 기반 권한 부여 메커니즘입니다. SAS를 사용할 때 키는 연결 중에 전달되지 않습니다. 키는 서비스에 의해 나중에 확인될 수 있는 정보를 암호화하여 서명하는 데 사용됩니다. SAS는 클라이언트가 권한 부여 규칙 이름 및 일치 키를 즉시 소유하는 사용자 이름 및 암호 구성표와 유사하게 사용될 수 있습니다. SAS는 클라이언트가 서명 키를 소유하지 않고 보안 토큰 서비스에서 시간이 제한되고 서명된 액세스 토큰을 받는 페더레이션된 보안 모델과 유사하게 사용될 수 있습니다.

공유 액세스 권한 부여 정책

각 Event Hubs 네임스페이스와 각 Event Hubs 엔터티(이벤트 허브 또는 Kafka 토픽)에는 규칙으로 구성된 공유 액세스 권한 부여 정책이 있습니다. 네임스페이스 수준에서 정책은 개별 정책 구성에 관계 없이 네임스페이스 내부의 모든 엔터티에 적용됩니다.

각각의 권한 부여 정책 규칙의 경우 이름, 범위 및 권한 등, 3가지 정보를 결정합니다. 이름은 해당 범위 내에서 고유한 이름입니다. 범위는 해당 리소스의 URI입니다. Event Hubs 네임스페이스의 경우 범위는 https://<yournamespace>.servicebus.windows.net/ 등과 같이 FQDN(정규화된 도메인 이름)입니다.

정책 규칙에 따른 권한은 다음의 조합일 수 있습니다.

• Send – 엔터티에 메시지를 보낼 수 있는 권한을 부여합니다.
• Listen - 엔터티에서 메시지를 수신 대기하거나 받을 수 있는 권한을 부여합니다.
• Manage – 엔터티 만들기 및 삭제를 포함하여 네임스페이스의 토폴로지를 관리할 수 있는 권한을 부여합니다. Manage 권한에는 Send 및 Listen 권한이 포함됩니다.

네임스페이스 또는 엔터티 정책은 각각 기본 권한 및 Send 및 Listen의 조합을 다루는 세 개의 규칙 세트를 위한 여지를 제공하여 최대 12개의 공유 액세스 권한 부여 규칙을 포함할 수 있습니다. 이러한 제한은 SAS 정책 저장소가 사용자 또는 서비스 계정 저장소를 의도하지 않았음을 명확하게 나타냅니다. 애플리케이션에서 사용자 또는 서비스 ID에 따라 Event Hubs 리소스에 대한 액세스 권한을 부여해야 하는 경우 인증 및 액세스 검사 후 SAS 토큰을 발급하는 보안 토큰 서비스를 구현해야 합니다.

권한 부여 규칙은 기본 키 및 보조 키에 할당됩니다. 해당 키는 강력한 암호화 키입니다. 분실하거나 유출해서는 안 됩니다. 해당 키는 Azure Portal에서 항상 사용할 수 있습니다. 생성된 키 중 하나를 사용할 수 있으며 언제든지 다시 생성할 수 있습니다. 정책에서 키를 다시 생성하거나 변경하는 경우 해당 키에 기반한 이전에 발급된 모든 토큰은 즉시 무효화됩니다. 그러나 이러한 토큰에 따라 생성된 진행 중인 연결은 토큰이 만료될 때까지 작업을 계속합니다.

Event Hubs 네임스페이스를 만들 때 해당 네임스페이스에 대해 RootManageSharedAccessKey라는 정책 규칙이 자동으로 만들어집니다. 해당 정책은 전체 네임스페이스에 대한 Manage 사용 권한을 보유합니다. 해당 규칙을 관리 루트 계정과 같이 다루고 애플리케이션에서 사용하지 않는 것이 좋습니다. PowerShell 또는 Azure CLI를 통해 포털의 해당 네임스페이스에 대한 구성 탭에서 추가 정책 규칙을 만들 수 있습니다.

SAS를 사용하는 경우 모범 사례

애플리케이션에서 공유 액세스 서명을 사용할 경우 다음과 같은 두 가지 잠재적 위험에 대해 잘 알고 있어야 합니다.

• SAS가 유출된 경우 SAS를 획득한 모든 사용자가 이를 사용하여 Event Hubs 리소스를 손상시킬 수 있습니다.
• 클라이언트 애플리케이션에 제공된 SAS가 만료되고 애플리케이션이 서비스에서 새 SAS를 검색할 수 없는 경우 애플리케이션의 기능이 저하될 수 있습니다.

다음은 공유 액세스 서명을 사용하여 이러한 위험을 완화하는 데 도움이 될 수 있는 권장 사항입니다.

• 필요한 경우 클라이언트가 자동으로 SAS를 갱신하도록 함: 클라이언트는 만료일 이전에 SAS를 갱신하여 SAS를 제공하는 서비스를 사용할 수 없는 경우 다시 시도할 수 있는 시간적 여유를 확보해야 합니다. 만료 기간 내에 완료될 것으로 예상되는 소수의 즉각적이고 단기적인 작업에 SAS를 사용하려는 경우 SAS가 갱신되지 않을 것으로 예상되므로 불필요할 수 있습니다. 하지만 클라이언트가 SAS를 통해 일상 요청을 수행하는 경우에는 중간에 만료될 수 있습니다. 주요 고려 사항은 SAS의 수명이 짧아야 하는 필요성(앞서 언급한 대로)과 클라이언트가 충분히 일찍 갱신을 요청하는지 확인해야 하는 필요성(성공적인 갱신 전에 SAS 만료로 인한 중단을 방지하기 위해)의 균형을 맞추는 것입니다.
• SAS 시작 시간에 주의: SAS의 시작 시간을 지금으로 설정한 경우 클록 스큐(머신마다 현재 시간의 차이)로 인해 처음 몇 분 동안 간헐적으로 오류가 관찰될 수 있습니다. 일반적으로 시작 시간을 최소 15분 이전으로 설정하거나 또는 모든 경우에 즉시 유효하도록 전혀 설정하지 마세요. 이는 일반적으로 만료 시간에도 적용됩니다. 모든 요청에 대해 어떤 방향이든 최대 15분의 클록 스큐가 발생할 수 있습니다.
• 액세스할 리소스가 구체적이어야 함: 보안 모범 사례는 사용자에게 필요한 최소 권한을 제공하는 것입니다. 사용자가 단일 엔터티에 대한 읽기 권한만 필요한 경우 해당 엔터티에 대한 읽기 권한만 부여하고 모든 엔터티에 대한 읽기/쓰기/삭제 권한은 부여하지 않습니다. 또한 SAS가 공격자의 수중에 넘어갈 가능성이 낮아지므로 SAS가 손상될 경우 손해가 줄어듭니다.
• 항상 SAS를 사용하지 않음: Event Hubs에 대한 특정 작업 관련 위험이 SAS의 이점을 능가하는 경우도 있습니다. 이러한 작업의 경우 비즈니스 규칙 유효성 검사, 인증 및 감사 후에 이벤트 허브에 쓰는 중간 계층 서비스를 만듭니다.
• 항상 HTTP 사용: 항상 HTTPS를 사용하여 SAS를 만들거나 배포합니다. HTTP를 통해 SAS를 전달할 경우 SAS가 노출되면 메시지 가로채기(man-in-the-middle) 공격을 수행하는 공격자가 SAS를 읽은 다음 의도된 사용자처럼 SAS를 사용할 수 있으므로, 악의적인 사용자가 중요한 데이터를 손상시킬 수 있습니다.

결론

공유 액세스 서명은 클라이언트에 Event Hubs 리소스에 대한 제한된 권한을 제공하는 데 유용합니다. Azure Event Hubs를 사용하는 모든 애플리케이션에 대한 보안 모델의 중요한 부분입니다. 이 문서에 나열된 모범 사례를 따르면 애플리케이션의 보안을 손상시키지 않고 SAS를 사용하여 리소스에 더 많은 유연성을 제공할 수 있습니다.

관련 콘텐츠

다음 관련 문서를 참조하세요.

• 공유 액세스 서명을 사용하여 Azure Event Hubs에 대한 요청 인증
• Microsoft Entra ID를 사용하여 애플리케이션에서 Azure Event Hubs에 대한 요청 인증
• Event Hubs 리소스에 액세스하려면 Microsoft Entra ID로 관리 ID를 인증합니다.