Azure AI Search에 대한 보안 개요

이 문서에서는 데이터 및 작업을 보호하는 Azure AI Search의 보안 기능에 대해 설명합니다.

데이터 흐름(네트워크 트래픽 패턴)

Azure AI Search 서비스는 Azure에서 호스트되며, 일반적으로 공용 네트워크 연결을 통해 클라이언트 애플리케이션에서 액세스합니다. 이 패턴이 우세하지만, 주의해야 하는 유일한 트래픽 패턴은 아닙니다. 모든 진입점과 아웃바운드 트래픽을 이해하는 것은 개발 및 프로덕션 환경을 보호하는 데 필요한 배경 지식입니다.

Azure AI Search에는 다음과 같은 세 가지 기본 네트워크 트래픽 패턴이 있습니다.

  • 검색 서비스에 대한 클라이언트의 인바운드 요청(주요 패턴)
  • Azure 및 다른 위치의 다른 서비스에 대해 검색 서비스에서 실행한 아웃바운드 요청
  • 보안 Microsoft 백본 네트워크를 통한 내부 서비스 간 요청

인바운드 트래픽

검색 서비스 엔드포인트를 대상으로 하는 인바운드 요청에는 다음이 포함됩니다.

  • 검색 서비스에서 개체 만들기, 읽기, 업데이트 또는 삭제
  • 검색 문서가 포함된 인덱스 로드
  • 인덱스 쿼리
  • 인덱서 또는 기술 세트 실행 트리거

REST API는 검색 서비스에서 처리하는 전체 범위의 인바운드 요청을 설명합니다.

최소한 모든 인바운드 요청은 다음 옵션 중 하나를 사용하여 인증되어야 합니다.

  • 키 기반 인증(기본값). 인바운드 요청은 유효한 API 키를 제공합니다.
  • 역할 기반 액세스 제어. 권한 부여는 검색 서비스에 대한 Microsoft Entra ID 및 역할 할당을 통해 이루어집니다.

또한 네트워크 보안 기능을 추가하여 엔드포인트에 대한 액세스를 추가로 제한할 수 있습니다. IP 방화벽에서 인바운드 규칙을 만들거나 퍼블릭 인터넷에서 검색 서비스를 완전히 보호하는 프라이빗 엔드포인트를 만들 수 있습니다.

내부 트래픽

내부 요청은 Microsoft에서 보호하고 관리합니다. 이러한 연결은 구성하거나 제어할 수 없습니다. 네트워크 액세스를 잠그는 경우 고객이 내부 트래픽을 구성할 수 없으므로 사용자 쪽의 작업이 필요하지 않습니다.

내부 트래픽은 다음으로 구성됩니다.

아웃바운드 트래픽

아웃바운드 요청은 사용자가 보호하고 관리할 수 있습니다. 아웃바운드 요청은 검색 서비스에서 다른 애플리케이션으로 시작됩니다. 이러한 요청은 일반적으로 텍스트 기반 인덱싱, 기술 기반 AI 보강 및 쿼리 시 벡터화를 위해 인덱서에 의해 이루어집니다. 아웃바운드 요청에는 읽기 및 쓰기 작업이 모두 포함됩니다.

다음 목록에 보안 연결을 구성할 수 있는 아웃바운드 요청이 모두 열거됩니다. 검색 서비스는 자체적으로 요청하거나 인덱서 또는 사용자 지정 기술을 대신하여 요청합니다.

연산 시나리오
인덱서 데이터를 검색하려면 외부 데이터 원본에 연결합니다. 자세한 콘텐츠는 Azure 네트워크 보안으로 보호되는 콘텐츠에 대한 인덱서 액세스를 참조하세요.
인덱서 Azure Storage에 연결하여 지식 저장소, 캐시된 보강, 디버그 세션을 유지합니다.
사용자 지정 기술 Azure 함수, Azure 웹앱 또는 서비스 외부에서 호스트되는 외부 코드를 실행하는 기타 앱에 연결합니다. 외부 처리 요청은 기술 세트 실행 중에 보내집니다.
인덱서 및 통합 벡터화 Azure OpenAI 및 배포된 포함 모델에 연결하거나, 사용자 지정 기술을 통해 사용자가 제공하는 포함 모델에 연결합니다. 검색 서비스는 인덱싱 중에 벡터화를 위해 포함 모델에 텍스트를 보냅니다.
벡터라이저 벡터 검색을 위해 쿼리 시 Azure OpenAI 또는 기타 포함 모델에 연결하여 사용자 텍스트 문자열을 벡터로 변환합니다.
Search Service 중요한 데이터를 암호화하고 해독하는 데 사용되는 고객 관리 암호화 키를 위해 Azure Key Vault에 연결합니다.

Microsoft Entra ID 및 역할 기반 액세스를 사용하는 경우 키 또는 데이터베이스 로그인, 관리 ID가 포함된 리소스의 전체 액세스 연결 문자열을 사용하여 아웃바운드 연결을 만들 수 있습니다.

방화벽 뒤에 있는 Azure 리소스에 접근하려면 검색 서비스 요청을 허용하는 다른 Azure 리소스에 대한 인바운드 규칙을 만듭니다.

Azure Private Link로 보호되는 Azure 리소스에 연결하려면 인덱서가 연결을 위해 사용하는 공유 Private Link를 만듭니다.

동일 지역 검색 및 스토리지 서비스 예외

Azure Storage와 Azure AI Search가 동일한 지역에 있는 경우 네트워크 트래픽은 개인 IP 주소를 통해 라우팅되고 Microsoft 백본 네트워크를 통해 발생합니다. 개인 IP 주소가 사용되므로 네트워크 보안을 위해 IP 방화벽 또는 프라이빗 엔드포인트를 구성할 수 없습니다.

다음 방법 중 하나를 사용하여 동일한 지역 연결을 구성합니다.

네트워크 보안

네트워크 보안은 제어를 네트워크 트래픽에 적용하여 무단 액세스 또는 공격으로부터 리소스를 보호합니다. Azure AI Search는 무단 액세스에 대한 최전방 방어선이 될 수 있는 네트워킹 기능을 지원합니다.

IP 방화벽을 통한 인바운드 연결

검색 서비스는 공용 IP 주소를 사용하여 액세스를 허용하는 공용 엔드포인트를 통해 프로비전됩니다. 공용 엔드포인트를 통해 들어오는 트래픽을 제한하려면 특정 IP 주소 또는 IP 주소 범위의 요청을 허용하는 인바운드 방화벽 규칙을 만듭니다. 모든 클라이언트 연결은 허용된 IP 주소를 통해 수행되어야 합니다. 그렇지 않으면 연결이 거부됩니다.

IP 제한 액세스에 대한 샘플 아키텍처 다이어그램

포털을 사용하여 방화벽 액세스를 구성할 수 있습니다.

또는 관리 REST API를 사용할 수 있습니다. API 버전 2020-03-13부터 IpRule 매개 변수를 사용하면 검색 서비스에 대한 액세스 권한을 부여하려는 IP 주소를 개별적으로 또는 범위에서 식별하여 서비스에 대한 액세스를 제한할 수 있습니다.

프라이빗 엔드포인트에 대한 인바운드 연결(네트워크 격리, 인터넷 트래픽 없음)

더 엄격한 보안을 위해 Azure AI Search에 대한 프라이빗 엔드포인트를 설정할 수 있습니다. 그러면 가상 네트워크의 클라이언트에서 프라이빗 링크를 통해 검색 인덱스의 데이터에 안전하게 액세스할 수 있습니다.

프라이빗 엔드포인트는 검색 서비스에 연결하기 위해 가상 네트워크 주소 공간의 IP 주소를 사용합니다. 클라이언트와 검색 서비스 간의 네트워크 트래픽은 가상 네트워크와 Microsoft 백본 네트워크의 프라이빗 링크를 통과하여 퍼블릭 인터넷에서 공개되지 않도록 합니다. 가상 네트워크를 사용하면 온-프레미스 네트워크 및 인터넷을 통해 리소스 간에 안전하게 통신할 수 있습니다.

프라이빗 엔드포인트 액세스에 대한 샘플 아키텍처 다이어그램

이 솔루션은 가장 안전하지만, 추가 서비스를 사용하면 추가 비용이 발생하므로 자세히 살펴보기 전에 혜택을 명확히 이해하고 있어야 합니다. 비용에 대한 자세한 내용은 가격 책정 페이지를 참조하세요. 이러한 구성 요소가 함께 작동하는 방법에 대한 자세한 내용은 이 비디오를 시청하세요. 프라이빗 엔드포인트 옵션의 적용 범위는 비디오의 5분 48초 지점에서 시작됩니다. 엔드포인트를 설정하는 방법에 대한 지침은 에 대한 프라이빗 엔드포인트 만들기를 참조하세요.

인증

검색 서비스에 대한 요청이 승인되면 요청이 허용되는지 여부를 결정하는 인증 및 권한 부여도 거쳐야 합니다. Azure AI Search에서 지원하는 두 가지 방법은 다음과 같습니다.

  • 인증은 요청이 아닌 호출자를 인증된 ID로 설정합니다. Azure 역할 할당은 권한 부여를 결정합니다.

  • 키 기반 인증은 API 키를 통해 요청(호출 앱 또는 사용자가 아님)에 대해 수행됩니다. 여기서 키는 요청이 신뢰할 수 있는 원본에서 온 것임을 증명하는 임의로 생성된 숫자와 문자로 구성된 문자열입니다. 모든 요청에 키가 필요합니다. 유효한 키를 제출하면 요청이 신뢰할 수 있는 엔터티에서 시작되었다는 증명으로 간주됩니다.

두 인증 방법을 모두 사용하거나 검색 서비스에서 사용할 수 없는 접근 방식을 사용하지 않도록 설정할 수 있습니다.

Authorization

Azure AI Search는 서비스 관리 및 콘텐츠 관리를 위한 권한 부여 모델을 제공합니다.

서비스 관리 승인

리소스 관리는 Microsoft Entra 테넌트의 역할 기반 액세스 제어를 통해 권한 부여됩니다.

Azure AI Search에서 Resource Manager는 서비스를 만들거나 삭제하고, API 키를 관리하고, 서비스를 스케일링하고, 보안을 구성하는 데 사용됩니다. 따라서 Azure 역할 할당은 포털, PowerShell 또는 Management REST API를 사용하는지 여부에 관계없이 이러한 작업을 수행할 수 있는 사용자를 결정합니다.

검색 서비스 관리에는 세 가지 기본 역할(소유자, 기여자, 읽기 권한자)이 적용됩니다. 역할 할당은 지원되는 모든 방법(포털, PowerShell 등)을 사용하여 수행할 수 있으며 서비스 전체에 적용됩니다.

참고 항목

Azure 전체 메커니즘을 사용하여 구독 또는 리소스를 잠가서 관리자 권한이 있는 사용자가 검색 서비스를 실수로 삭제하거나 무단으로 삭제하는 것을 방지할 수 있습니다. 자세한 내용은 예기치 않은 삭제를 방지하기 위해 리소스 잠그기를 참조하세요.

콘텐츠에 대한 액세스 권한 부여

콘텐츠 관리는 검색 서비스에서 만들어지고 호스트되는 개체를 나타냅니다.

  • 역할 기반 권한 부여의 경우 Azure 역할 할당을 사용하여 작업에 대한 읽기-쓰기 액세스 권한을 설정합니다.

  • 키 기반 권한 부여의 경우 API 키와 정규화된 엔드포인트에 따라 액세스 권한이 결정됩니다. 엔드포인트는 서비스 자체, 인덱스 컬렉션, 특정 인덱스, 문서 컬렉션 또는 특정 문서일 수 있습니다. 함께 연결하면 엔드포인트, 작업(예: 만들기 또는 업데이트 요청) 및 키 유형(관리 또는 쿼리)이 콘텐츠 및 작업에 대한 액세스 권한을 부여합니다.

인덱스에 대한 액세스 제한

Azure 역할을 사용하는 경우 프로그래밍 방식으로 수행되는 한, 개별 인덱스에 대한 권한을 설정할 수 있습니다.

키를 사용하는 경우 서비스에 대한 관리자 키가 있는 모든 사용자는 동일한 서비스에서 모든 인덱스를 읽거나, 수정하거나, 삭제할 수 있습니다. 인덱스를 실수로 또는 악의적으로 삭제하지 못하도록 방지하기 위해 코드 자산에 대한 원본을 내부적으로 제어하여 원치 않는 인덱스 삭제 또는 수정을 되돌릴 수 있는 솔루션입니다. Azure AI Search는 가용성을 보장하기 위해 클러스터 내에서 장애 조치(failover)를 수행하지만 인덱스를 만들거나 로드하는 데 사용되는 독점 코드를 저장하거나 실행하지 않습니다.

인덱스 수준에서 보안 경계가 필요한 다중 테넌트 솔루션의 경우 애플리케이션 코드의 중간 계층에서 인덱스 격리를 처리하는 것이 일반적입니다. 다중 테넌트 사용 사례에 대한 자세한 내용은 다중 테넌트 SaaS 애플리케이션 및 Azure AI Search에 대한 디자인 패턴을 참조하세요.

문서에 대한 액세스 제한

행 수준 보안이라고도 하는 문서 수준의 사용자 권한은 Azure AI Search에서 기본적으로 지원되지 않습니다. Azure Cosmos DB와 같은 행 수준 보안을 제공하는 외부 시스템에서 데이터를 가져오는 경우 해당 권한은 Azure AI Search에서 인덱싱되는 데이터와 함께 전송되지 않습니다.

검색 결과에서 콘텐츠에 대한 권한 있는 액세스가 필요한 경우 사용자 ID에 따라 문서를 포함하거나 제외하는 필터를 적용하는 기술이 있습니다. 이 해결 방법은 그룹 또는 사용자 ID를 나타내는 문자열 필드를 데이터 원본에 추가하여 인덱스에서 필터링할 수 있도록 하는 것입니다. 다음 표에서는 권한이 없는 콘텐츠의 검색 결과를 잘라내는 방법에 대한 두 가지 방법을 설명합니다.

접근법 설명
ID 필터에 따라 보안 조정 사용자 ID 액세스 제어를 구현하기 위한 기본 워크플로를 문서화합니다. 인덱스에 보안 식별자를 추가하는 방법을 다루고 금지된 콘텐츠의 결과를 잘라내는 해당 필드에 대한 필터링을 설명합니다.
Microsoft Entra ID에 따른 보안 조정 이 문서는 이전 문서에서 확장되어 Azure 클라우드 플랫폼에서 제공하는 체험 서비스 중 하나인 Microsoft Entra ID에서 ID를 검색하는 단계를 제공합니다.

데이터 보존

검색 서비스를 설정할 때 고객 데이터가 저장되고 처리되는 위치를 결정하는 위치 또는 지역을 선택합니다. Azure AI Search는 다른 Azure 리소스에 대한 종속성이 있는 기능을 구성하고 해당 리소스가 다른 지역에 프로비전되지 않는 한, 지정된 지역 외부에 고객 데이터를 저장하지 않습니다.

현재 검색 서비스가 쓰는 유일한 외부 리소스는 Azure Storage입니다. 스토리지 계정은 사용자가 제공하는 계정이며 모든 지역에 있을 수 있습니다. 검색 서비스는 보강 캐시, 디버그 세션, 지식 저장소 기능 중 하나를 사용하는 경우 Azure Storage에 씁니다.

데이터 보존 약정에 대한 예외

개체 이름은 선택한 지역 또는 위치 외부에서 저장 및 처리됩니다. 고객은 이름 필드에 중요한 데이터를 배치하거나 이러한 필드에 중요한 데이터를 저장하도록 설계된 애플리케이션을 만들어서는 안 됩니다. 이 데이터는 서비스에 대한 지원을 제공하기 위해 Microsoft에서 사용하는 원격 분석 로그에 나타납니다. 개체 이름에는 인덱스, 인덱서, 데이터 원본, 기술 세트, 리소스, 컨테이너 및 키 자격 증명 모음 저장소의 이름이 포함됩니다.

원격 분석 로그는 1년 반 동안 유지됩니다. 이 기간 동안 Microsoft는 다음 조건에서 개체 이름에 액세스하고 참조할 수 있습니다.

  • 문제를 진단하고 기능을 개선하거나 버그를 수정합니다. 이 시나리오에서 데이터 액세스는 타사 액세스 없이 내부 전용입니다.

  • 지원 중에 이 정보는 문제에 대한 빠른 해결을 제공하고 필요한 경우 제품 팀을 에스컬레이션하는 데 사용될 수 있습니다.

데이터 보호

스토리지 계층에서는 인덱스, 동의어 맵, 인덱서, 데이터 원본 및 기술 세트의 정의를 포함하여 디스크에 저장된 모든 서비스 관리 콘텐츠에 대해 데이터 암호화가 기본적으로 제공됩니다. 서비스 관리 암호화는 장기 데이터 스토리지와 임시 데이터 스토리지 모두에 적용됩니다.

선택적으로 미사용 데이터의 이중 암호화를 위해 인덱싱된 콘텐츠의 추가 암호화를 위해 CMK(고객 관리형 키)를 추가할 수 있습니다. 2020년 8월 1일 이후에 만들어진 서비스의 경우 CMK 암호화가 임시 디스크의 단기 데이터로 확장됩니다.

전송 중 데이터

Azure AI Search에서 암호화는 연결 및 전송으로 시작됩니다. 퍼블릭 인터넷에서 수행되는 검색 서비스의 경우 Azure AI Search는 HTTPS 포트 443에서 수신 대기합니다. 모든 클라이언트-서비스 연결은 TLS 1.2 암호화를 사용합니다. 이전 버전(1.0 또는 1.1)은 지원되지 않습니다.

미사용 데이터

검색 서비스에서 내부적으로 처리하는 데이터의 경우 다음 표에서 데이터 암호화 모델에 대해 설명합니다. 지식 저장소, 증분 보강 및 인덱서 기반 인덱싱과 같은 일부 기능은 다른 Azure 서비스의 데이터 구조에서 읽거나 씁니다. Azure Storage에 종속된 서비스는 해당 기술의 암호화 기능을 사용할 수 있습니다.

모델 구성 요구 사항 제한 사항 적용 대상:
서버 쪽 암호화 Microsoft 관리형 키 없음(기본 제공) 없음. 2018년 1월 24일 이후에 만들어진 콘텐츠의 경우 모든 지역의 모든 계층에서 사용할 수 있습니다. 데이터 디스크 및 임시 디스크의 콘텐츠(인덱스 및 동의어 맵) 및 정의(인덱서, 데이터 원본, 기술 세트)
서버 쪽 암호화 사용하여 암호화 Azure Key Vault 2020년 8월 1일 이후에 만들어진 콘텐츠에 대해 특정 지역의 청구 가능 계층에서 사용할 수 있습니다. 데이터 디스크의 콘텐츠(인덱스 및 동의어 맵)
서버 쪽 전체 암호화 사용하여 암호화 Azure Key Vault 2021년 5월 13일 이후 검색 서비스에서 모든 지역의 청구 가능한 계층에서 사용할 수 있습니다. 데이터 디스크 및 임시 디스크의 콘텐츠(인덱스 및 동의어 맵)

서비스 관리형 키

서비스 관리 암호화는 256비트 AES 암호화를 사용하는 Microsoft 내부 작업입니다. 완전히 암호화되지 않은 인덱스(2018년 1월 이전에 만들어짐)에 대한 증분 업데이트를 포함하여 모든 인덱싱에서 자동으로 수행됩니다.

서비스 관리 암호화는 장기 및 단기 스토리지의 모든 콘텐츠에 적용됩니다.

CMK(고객 관리형 키)

고객 관리형 키에는 Azure AI Search와 같이 다른 지역에 있지만 동일한 구독에 있을 수 있는 다른 청구 가능 서비스인 Azure Key Vault가 필요합니다.

CMK 지원은 두 단계로 진행되었습니다. 첫 번째 단계에서 검색 서비스를 만든 경우 CMK 암호화는 장기 스토리지 및 특정 지역으로 제한되었습니다. 2021년 5월 이후 두 번째 단계에서 만들어진 서비스는 모든 지역에서 CMK 암호화를 사용할 수 있습니다. 2차 롤아웃의 일환으로 콘텐츠는 장기 및 단기 스토리지 모두에서 CMK로 암호화됩니다. CMK 지원에 대한 자세한 내용은 완전 이중 암호화를 참조하세요.

CMK 암호화를 사용하도록 설정하면 인덱스 크기가 증가하고 쿼리 성능이 저하됩니다. 현재까지 관찰한 결과에 따르면 실제 성능은 인덱스 정의 및 쿼리 유형에 따라 다르지만 쿼리 시간이 30~60% 증가하는 것으로 예상할 수 있습니다. 성능에 부정적인 영향을 미치기 때문에 실제로 필요한 인덱스에서만 이 기능을 사용하도록 설정하는 것이 좋습니다. 자세한 내용은 에서 고객 관리형 암호화 키 구성을 참조하세요.

보안 관리

API 키 관리

API 키 기반 인증을 사용하는 것은 Azure 보안 모범 사례에 따라 관리자 키를 정기적으로 다시 생성하기 위한 계획이 있어야 함을 의미합니다. 검색 서비스당 최대 2개의 관리자 키가 있습니다. API 키를 보호하고 관리하는 방법에 대한 자세한 내용은 api-key 만들기 및 관리를 참조하세요.

활동 및 리소스 로그

Azure AI Search는 사용자 ID를 로그하지 않으므로 특정 사용자의 정보에 대한 로그를 참조할 수 없습니다. 그러나 서비스에서 로그 만들기-읽기-업데이트-삭제 작업을 수행하므로 특정 작업의 에이전시를 이해하기 위해 다른 로그와 상호 연결할 수 있습니다.

Azure의 경고 및 로깅 인프라를 사용하여 쿼리 볼륨 급증 또는 예상되는 워크로드에서 벗어난 다른 작업을 선택할 수 있습니다. 로그를 설정하는 방법에 대한 자세한 내용은 로그 데이터 수집 및 분석쿼리 요청 모니터링을 참조하세요.

인증 및 규정 준수

Azure AI Search는 정기적인 감사에 참가하고, 퍼블릭 클라우드와 Azure Government 모두의 다양한 글로벌, 지역 및 산업별 표준에 대해 인증을 받았습니다. 전체 목록은 공식 감사 보고서 페이지에서 Microsoft Azure 규정 준수 제안 백서를 다운로드하세요.

규정 준수를 위해 Azure Policy를 사용하여 높은 수준의 Microsoft 클라우드 보안 벤치마크 보안 모범 사례를 구현할 수 있습니다. Microsoft 클라우드 보안 벤치마크는 서비스 및 데이터에 대한 위협을 완화하기 위해 수행해야 하는 주요 작업에 매핑되는 보안 제어로 성문화된 보안 권장 사항의 모음입니다. 현재 네트워크 보안, 로깅 및 모니터링, 데이터 보호를 포함하여 12개의 보안 제어가 있습니다.

Azure Policy는 Microsoft 클라우드 보안 벤치마크를 포함하여 여러 표준에 대한 규정 준수를 관리하는 데 도움이 되는 Azure에 기본 제공되는 기능입니다. 잘 알려진 벤치마크의 경우 Azure Policy는 비준수 문제를 해결하는 조건 및 실행 가능한 응답을 모두 제공하는 기본 제공 정의를 제공합니다.

Azure AI Search의 경우 현재 하나의 기본 제공 정의가 있습니다. 이는 리소스 로깅에 대한 정의입니다. 리소스 로깅이 없는 검색 서비스를 식별하는 정책을 할당한 다음, 이 로깅을 설정할 수 있습니다. 자세한 내용은 에 대한 Azure Policy 규정 준수 제어를 참조하세요.

이 비디오 보기

보안 아키텍처 및 각 기능 범주에 대한 개요를 보려면 아래의 빠른 학습 비디오를 시청하세요.

참고 항목