Bot Framework 보안 및 개인 정보 보호 질문과 대답

각 봇에는 자체 서비스가 있고 이러한 서비스의 개발자는 개발자 준수 사항에 따라 서비스 약관 및 개인정보처리방침을 제공해야 합니다. 자세한 내용은 봇 검토 지침을 참조 하세요.

예. 봇은 인터넷의 어디에서나 호스팅할 수 있습니다. 사용자 고유의 서버, Azure 또는 다른 데이터 센터에서. 유일한 요구 사항은 봇이 공개적으로 액세스할 수 있는 HTTPS 엔드포인트를 노출해야 한다는 것입니다.

사용자는 디렉터리에 있는 봇의 연락처 카드를 통해 오작동하는 봇을 보고할 수 있습니다. 개발자는 서비스에 참여하려면 Microsoft 서비스 약관을 준수해야 합니다.

봇에서 인터넷으로의 트래픽을 차단하는 아웃바운드 방화벽이 있는 경우 해당 방화벽에서 다음 URL을 허용 목록에 추가해야 합니다.

• login.botframework.com (봇 인증)
• login.microsoftonline.com (봇 인증)
• westus.api.cognitive.microsoft.com(Luis.ai NLP 통합의 경우)
• *.botframework.com (채널)
• state.botframework.com(이전 버전과의 호환성)
• login.windows.net(Windows 로그인)
• login.windows.com(Windows 로그인)
• sts.windows.net(Windows 로그인)
• 특정 Bot Framework 채널에 대한 기타 URL

Bot Framework Services는 전 세계 Azure 데이터 센터에서 호스트되며 Azure IP 목록은 지속적으로 변경되고 있습니다. 즉, 특정 IP 주소를 허용 나열하면 하루가 작동하고 Azure IP 주소가 변경되면 다음 IP 주소가 중단됩니다.

Azure Portal에서 봇을 만들려면 구독 또는 특정 리소스 그룹에 기여자 액세스 권한이 필요합니다. 리소스 그룹에서 기여자 역할이 있는 사용자는 새 봇을 해당 리소스 그룹에 만들 수 있습니다. 구독에 대한 기여자 역할의 사용자는 새 리소스 그룹 또는 기존 리소스 그룹에 봇을 만들 수 있습니다.

Azure CLI를 사용하여 역할 기반 액세스 제어 접근 방식은 사용자 지정 역할을 지원할 수 있습니다. 더 제한된 권한으로 사용자 지정 역할을 수행하려는 경우 아래 집합을 통해 사용자는 LUIS, QnA Maker 및 Application Insights를 지원하는 봇을 만들고 배포할 수 있습니다.

"Microsoft.Web/*",
"Microsoft.BotService/*",
"Microsoft.Storage/*",
"Microsoft.Resources/deployments/*",
"Microsoft.CognitiveServices/*",
"Microsoft.Search/searchServices/*",
"Microsoft.Insights/*",
"Microsoft.Insights/components/*"

1. 모든 인증 Bot Framework 요청에는 인증 가이드에 따라 암호화 서명을 확인할 수 있는 JWT 토큰이 함께 제공됩니다. 토큰은 공격자가 신뢰할 수 있는 서비스를 가장할 수 없도록 설계되었습니다.
2. 봇에 대한 모든 요청에 수반되는 보안 토큰에는 ServiceUrl이 인코딩되어 있습니다. 즉, 공격자가 토큰에 대한 액세스 권한을 얻더라도 대화를 새 ServiceUrl로 리디렉션할 수 없습니다. 이는 SDK의 모든 구현에 의해 적용되며 인증 참조 자료에 설명되어 있습니다.
3. 들어오는 토큰이 없거나 형식이 잘못된 경우 Bot Framework SDK는 응답으로 토큰을 생성하지 않습니다. 이렇게 하면 봇이 잘못 구성된 경우 수행할 수 있는 피해가 제한됩니다.
4. 봇 내에서 토큰에 제공된 ServiceUrl을 수동으로 검사 수 있습니다. 이렇게 하면 서비스 토폴로지 변경 시 봇이 더 취약해지므로 가능하지만 권장되지는 않습니다.

웹 채팅 컨트롤에는 적절한 사용자가 로그인되도록 보장하는 두 가지 메커니즘이 있습니다.

1. 매직 코드. 로그인 프로세스가 끝나면 사용자에게 임의로 생성된 6자리 코드(매직 코드)가 표시됩니다. 사용자가 로그인 프로세스를 완료하려면 대화에 이 코드를 입력해야 합니다. 이로 인해 사용자의 환경이 저하되는 경향이 있습니다. 또한 여전히 피싱 공격에 취약합니다. 악의적인 사용자가 다른 사용자를 속여 로그인하고 피싱을 통해 매직 코드를 가져올 수 있습니다.

   Warning

   매직 코드의 사용은 더 이상 사용되지 않습니다. 대신 아래에 설명된 직접 회선 강화 인증을 사용해야 합니다.

2. 직접 회선 강화 인증. 매직 코드 접근 방식의 문제로 인해 Azure AI Bot Service는 필요를 제거했습니다. Azure AI Bot Service는 로그인 프로세스가 웹 채팅 자체와 동일한 브라우저 세션에서만 완료될 수 있도록 보장합니다. 이 보호를 사용하려면 봇의 웹 채팅 클라이언트를 호스트할 수 있는 신뢰할 수 있는 원본 목록(신뢰할 수 있는 기본)이 포함된 직접 회선 토큰으로 웹 채팅 시작해야 합니다. 향상된 인증 옵션을 사용하면 Direct Line 구성 페이지에서 신뢰할 수 있는 원본 목록을 정적으로 지정할 수 있습니다. 자세한 내용은 Direct Line 고급 인증을 참조하세요.

IAM(ID 및 액세스 관리)은 적절한 사용자가 기술 리소스에 적절하게 액세스할 수 있도록 하는 프레임워크(정책 및 기술)입니다. 자세한 내용은 ID 관리를 참조하세요.

Bot Framework는 다음과 같은 식별 메커니즘을 제공합니다.

• 봇 인증. 요청이 합법적인 원본에서 왔는지 여부를 확인합니다. 봇 커넥터 서비스에서 제어하며 봇과 채널 간의 보안 통신을 가능하게 합니다. 자세한 내용은 봇 인증을 참조하세요.

• 사용자 인증. 이를 통해 봇은 사용자를 대신하여 보안 온라인 리소스에 액세스할 수 있습니다. 업계 표준 OAuth는 사용자를 인증하고 리소스에 액세스하도록 봇에 권한을 부여하는 데 사용됩니다. 자세한 내용은 사용자 인증을 참조하세요.

요약하자면, Bot Framework는 서비스 간 인증(봇 인증)을 처리하며, 기본적으로 요청이 실제로 적절한 채널에서 왔는지 확인합니다. 봇은 낮은 수준의 인증을 처리합니다. 봇이 특정 테넌트 ID의 요청만 수락하도록 필터를 적용하거나 사용자가 일부 OAuth 서비스(사용자 인증)로 인증하도록 요구할 수 있습니다.

봇이 처리하는 들어오는 메시지를 제한하는 두 가지 옵션이 있습니다.

• 보안 데이터를 처리하는 경우 OAuth를 사용하여 사용자를 인증하는 것이 좋습니다.

• 미들웨어를 사용하는 것도 좋은 옵션입니다. 예를 들어 Teams 채널에서 미들웨어를 만들어 Teams 채널 데이터에서 테넌트 ID를 가져올 수 있습니다. 그러면 미들웨어는 들어오는 작업을 봇 논리로 계속할지 아니면 오류 메시지를 반환할지 여부를 결정할 수 있습니다.

  Warning

  Teams가 다양한 테넌트에서 메시지를 보내는 것을 방지할 수 없으며, 앱 매니페스트가 있는 경우 다른 사용자가 봇을 설치하지 못하게 할 수도 없습니다. 봇이 원치 않는 메시지를 처리하지 못하도록 하기만 하면 됩니다.