다음을 통해 공유

보안 및 비즈니스용 Skype Online

  • 아티클
  • 적용 대상:
    Skype for Business, Skype for Business Online, Microsoft Teams

중요

중국에서 21Vianet이 운영하는 비즈니스용 Skype Online은 2023년 10월 1일에 사용 중지됩니다. 비즈니스용 Skype Online 사용자를 아직 업그레이드하지 않은 경우 보조 업그레이드가 자동으로 예약됩니다. organization 직접 Teams로 업그레이드하려면 지금 업그레이드 경로를 계획하는 것이 좋습니다. 성공적인 업그레이드는 기술 및 사용자 준비 상태를 조정하므로 Teams로의 여정을 탐색할 때 업그레이드 지침을 활용해야 합니다.

중국에서 21Vianet에서 운영하는 서비스를 제외한 비즈니스용 Skype Online은 2021년 7월 31일에 사용 중지되었습니다.

Microsoft 365 및 Office 365 서비스의 일부인 SfBO(비즈니스용 Skype Online)는 심층 방어, 서비스 내 고객 제어, 보안 강화 및 운영 모범 사례를 통해 서비스 수준 보안과 같은 모든 보안 모범 사례 및 절차를 따릅니다. 자세한 내용은 Microsoft 보안 센터(https://microsoft.com/trustcenter)를 참조하세요.

신뢰할 수 있는 설계

비즈니스용 Skype Online은 에 설명https://www.microsoft.com/sdl/default.aspx된 Microsoft Trustworthy Computing Security Development Lifecycle(SDL)을 준수하여 설계 및 개발되었습니다. 더욱 안전한 통합 커뮤니케이션 시스템을 만드는 첫 단계는 위협 모델을 설계하고 각 기능이 설계된 대로 작동하는지 테스트하는 것이었습니다. 보안과 관련하여 향상된 여러 기능이 코딩 프로세스 및 사례에 기본 제공되었습니다. 빌드 시간에 도구는 코드가 최종 제품에 체크 인되기 전에 버퍼 오버런 및 기타 잠재적인 보안 위협을 검색합니다. 알 수 없는 모든 보안 위협에 대해 설계하는 것은 불가능합니다. 시스템에서 완전한 보안을 보장할 수는 없습니다. 그러나 제품 개발은 처음부터 보안 디자인 원칙을 수용했기 때문에 비즈니스용 Skype Online은 업계 표준 보안 기술을 아키텍처의 기본 부분으로 통합합니다.

기본적인 신뢰성(Trustworthy by Default)

비즈니스용 Skype Online의 네트워크 통신은 기본적으로 암호화됩니다. 모든 서버에서 인증서를 사용하도록 요구하고 OAUTH, TLS, SRTP(Secure Real-Time Transport Protocol) 및 256비트 AES(Advanced Encryption Standard) 암호화를 비롯한 기타 업계 표준 암호화 기술을 사용하여 모든 비즈니스용 Skype 온라인 데이터가 네트워크에서 보호됩니다.

SfBO가 일반적인 보안 위협을 처리하는 방법

이 섹션에서는 SfBO 서비스의 보안에 대한 일반적인 위협과 Microsoft가 각 위협을 완화하는 방법을 식별합니다.

노출된 키 공격

키는 비밀 정보를 암호화, 암호 해독 또는 유효성 검사하는 데 사용되는 비밀 코드 또는 번호입니다. PKI(공개 키 인프라)에는 각 인증서 소유자가 가지고 있는 프라이빗 키와 통신 파트너가 성공적으로 식별한 후 사용되는 세션 키라는 두 가지 중요한 키가 있습니다. 손상된 키 공격은 공격자가 프라이빗 키 또는 세션 키를 결정할 때 발생합니다. 공격자가 키를 결정하는 데 성공하면 공격자는 키를 사용하여 보낸 사람의 지식 없이 암호화된 데이터의 암호를 해독할 수 있습니다.

비즈니스용 Skype Online은 Windows Server 운영 체제의 PKI 기능을 사용하여 TLS(전송 계층 보안) 연결에 암호화에 사용되는 키 데이터를 보호합니다. 미디어 암호화에 사용되는 키는 TLS 연결을 통해 교환됩니다.

네트워크 서비스 거부 공격

서비스 거부(DoS) 공격은 공격자가 유효한 사용자의 정상적인 네트워크 사용 및 작동을 막을 때 발생합니다. 공격자가 서비스 거부(DoS) 공격을 사용하여 수행할 수 있는 작업은 다음과 같습니다.

  • 공격하는 네트워크에서 실행되는 응용 프로그램 및 서비스에 유효하지 않은 데이터를 보내정상적인 작동을 막습니다.
  • 많은 양의 트래픽을 보내서 시스템이 정당한 요청에 응답하지 않거나 느리게 응답할 때까지 시스템에 과부하가 걸리게 합니다.
  • 공격의 증거를 숨깁니다.
  • 사용자가 네트워크 리소스에 액세스하지 못하게 막습니다.

SfBO는 Azure DDOS 네트워크 보호를 실행하고 동일한 엔드포인트, 서브넷 및 페더레이션된 엔터티에서 클라이언트 요청을 제한하여 이러한 공격을 완화합니다.

도청

공격자가 네트워크의 데이터 경로에 액세스할 수 있는 권한을 얻어 트래픽을 모니터링하고 읽을 수 있는 경우에 도청이 가능합니다. 다른 말로 스니핑(sniffing) 또는 스누핑(snooping)이라고도 합니다. 일반 텍스트 트래픽의 경우 공격자가 경로에 대한 액세스 권한을 얻으면 그러한 트래픽을 읽을 수 있습니다. 예를 들어 데이터 경로에 있는 라우터를 제어하여 공격을 수행합니다.

SfBO는 Microsoft 365 또는 클라이언트에서 서비스로의 Office 365 및 TLS 내의 서버 통신에 MTLS(상호 TLS)를 사용하여 지정된 대화가 공격될 수 있는 기간 내에 이 공격을 달성하기 어렵게 만듭니다. TLS는 모든 당사자를 인증하고 모든 트래픽을 암호화합니다. 이는 도청을 방지하지는 못하지만 암호화가 끊어지지 않는 한 공격자는 트래픽을 읽을 수 없습니다.

TURN 프로토콜은 실시간 미디어용으로 사용됩니다. TURN 프로토콜은 트래픽 암호화를 요구하지 않으며 전송하는 정보는 메시지 무결성으로 보호됩니다. 도청에 열려 있지만 전송하는 정보(즉, IP 주소 및 포트)는 패킷의 원본 및 대상 주소를 확인하여 직접 추출할 수 있습니다. SfBO 서비스는 명확한 텍스트로 전송되지 않는 TURN 암호를 포함하여 몇 가지 항목에서 파생된 키를 사용하여 메시지의 메시지 무결성을 확인하여 데이터가 유효한지 확인합니다. 미디어 트래픽에 SRTP가 사용되고 또한 암호화됩니다.

ID 스푸핑(IP 주소 스푸핑)

공격자가 권한이 없는데도 불구하고 네트워크, 컴퓨터 또는 네트워크 구성 요소의 IP 주소를 알아내어 사용하는 경우 스푸핑이 발생합니다. 공격이 성공하면 공격자가 IP 주소를 통해 일반적으로 식별되는 엔터티인 것처럼 작업할 수 있습니다. Microsoft Lync Server 2010의 컨텍스트 내에서 이 상황은 관리자가 다음을 모두 수행한 경우에만 발생합니다.

  • TCP(Transmission Control Protocol)만 지원하는 구성된 연결(TCP 통신은 암호화되지 않으므로 권장되지 않음).
  • 해당 연결의 IP 주소를 신뢰할 수 있는 호스트로 표시했습니다.

TLS는 모든 당사자를 인증하고 모든 트래픽을 암호화하므로 TLS(전송 계층 보안) 연결에 대한 문제가 적습니다. TLS를 사용하면 공격자가 특정 연결에 대해 IP 주소 스푸핑을 수행하는 것을 방지합니다(예: 상호 TLS 연결). 그러나 공격자는 여전히 SfBO에서 사용하는 DNS 서버의 주소를 스푸핑할 수 있습니다. 그러나 SfBO의 인증은 인증서를 사용하여 수행되므로 공격자는 통신의 당사자 중 하나를 스푸핑하는 데 필요한 유효한 인증서가 없습니다.

가로채기(Man-in-the-Middle) 공격

공격자가 통신하는 두 사용자에 대한 지식 없이 공격자의 컴퓨터를 통해 두 사용자 간의 통신 경로를 다시 라우팅할 때 맨인 더 중간 공격이 발생합니다. 공격자는 지정 수신인에게 전송하기에 앞서 트래픽을 모니터링하고 읽을 수 있습니다. 통신의 각 사용자는 의도한 사용자와만 통신하고 있다고 생각하면서 무의식적으로 트래픽을 보내고 공격자로부터 트래픽을 받습니다. 공격자가 Active Directory Domain Services를 수정하여 본인의 서버를 신뢰할 수 있는 서버로 추가하거나 DNS(Domain Name System)를 수정하여 클라이언트가 서버로 가는 도중에 공격자를 통과하여 연결하도록 허용하는 경우에 이 문제가 발생할 수 있습니다.

SfBO 지점 및 지점 간 오디오, 비디오 및 애플리케이션 공유 스트림은 TLS를 통해 SIP(세션 시작 프로토콜)를 사용하여 피어 간에 협상되는 암호화 키를 사용하여 SRTP로 암호화된다는 점을 제외하고 두 클라이언트 간의 미디어 트래픽에서도 맨인 더 중간 공격이 발생할 수 있습니다.

RTP 재생 공격

재생 공격은 두 당사자 같의 유효한 미디어 전송이 중간에 가로채여서 악의적인 목적으로 다시 전송될 때 발생합니다. SfBO는 수신기가 이미 수신된 RTP 패킷의 인덱스를 유지하고 각 새 패킷을 인덱스에 이미 나열된 패킷과 비교할 수 있도록 하여 재생 공격으로부터 전송을 보호하는 보안 신호 프로토콜과 SRTP를 사용합니다.

스핌

Spim은 원치 않는 상업용 인스턴트 메시지 또는 현재 상태 구독 요청입니다. 그 자체로 네트워크가 손상되는 것은 아니지만 최소한 성가신 일이며 리소스 가용성과 생산을 감소시킬 수 있으며 네트워크 손상으로 이어질 수 있습니다. 사용자 간에 서로 요청을 보내어 스핌하는 것을 예로 들 수 있습니다. 사용자는 이를 막기 위해 서로 차단할 수 있지만 페더레이션에서 조율된 스핌 공격이 이루어지는 경우 파트너에 대해 페더레이션을 사용하지 않도록 설정하지 않는 한 이를 극복하기가 어려울 수 있습니다.

바이러스 및 웜

바이러스는 유사한 코드 단위를 더 많이 재생산하는 것을 목적으로 하는 코드 단위입니다. 바이러스가 작동하기 위해서는 파일, 전자 메일 또는 프로그램 같은 호스트가 필요합니다. 바이러스와 마찬가지로 웜은 더 유사한 코드 단위를 재현하기 위해 코딩되는 코드 단위이지만 바이러스와 달리 호스트가 필요하지 않습니다. 바이러스와 웜은 주로 클라이언트 간 파일 전송 도중이나 다른 사용자로부터 URL이 전송될 때에 나타납니다. 컴퓨터에 바이러스가 있는 경우 예를 들어 사용자의 ID를 사용하여 사용자 대신 인스턴트 메시지를 보낼 수 있습니다. 주기적으로 바이러스를 검사하는 등의 표준 클라이언트 보안 모범 사례를 통해 이 문제를 완화시킬 수 있습니다.

개인 식별 정보

SfBO는 개인과 연결될 수 있는 공용 네트워크를 통해 정보를 공개할 가능성이 있습니다. 정보 유형은 다음 두 가지 특정 범주로 나눌 수 있습니다.

  • 향상된 현재 상태 데이터 향상된 현재 상태 데이터는 사용자가 페더레이션된 파트너 또는 organization 내의 연락처에 대한 링크를 통해 공유하거나 공유하지 않도록 선택할 수 있는 정보입니다. 이 데이터는 공용 IM 네트워크의 사용자와 공유되지 않습니다. 클라이언트 정책 및 기타 클라이언트 구성은 시스템 관리자에게 제어권을 부여할 수 있습니다. SfBO 서비스에서 SfBO 사용자가 사용자의 연락처 목록에 없는 사용자의 현재 상태 정보를 볼 수 없도록 개별 사용자에 대해 향상된 현재 상태 개인 정보 보호 모드를 구성할 수 있습니다.
  • 필수 데이터 필수 데이터는 서버 또는 클라이언트의 적절한 작업에 필요한 데이터입니다. 이는 라우팅, 상태 유지 관리 및 신호를 위해 서버 또는 네트워크 수준에서 필요한 정보입니다. 다음 표에는 SfBO가 작동하는 데 필요한 데이터가 나열되어 있습니다.

표 1 - 향상된 현재 상태 데이터

데이터 가능한 설정
개인 데이터 이름, 제목, 회사, Email 주소, 표준 시간대
전화 번호 회사, 모바일, 홈
일정 정보 약속 있음/없음, 마을 외 알림, 모임 세부 정보(일정에 액세스할 수 있는 사용자에게)
현재 상태 어웨이, 사용 가능, 사용 중, 방해 금지, 오프라인

표 2 - 필수 데이터

데이터 가능한 설정
IP 주소 컴퓨터 또는 NATed 주소의 실제 주소
SIP URI david.campbell@contoso.com
이름 데이비드 캠벨(Active Directory Domain Services 정의)

SfBO용 보안 프레임워크

이 섹션에서는 Microsoft SfBO에 대한 보안 프레임워크를 구성하는 기본 요소에 대한 개요를 제공합니다. 이러한 요소는 다음과 같습니다.

  • Microsoft Entra ID 사용자 계정에 대해 신뢰할 수 있는 단일 백 엔드 리포지토리를 제공합니다.
  • PKI(공개 키 인프라)는 신뢰할 수 있는 CA(인증 기관)에서 발급한 인증서를 사용하여 서버를 인증하고 데이터 무결성을 보장합니다.
  • TLS(전송 계층 보안), HTTPS(HTTPS를 통한 HTTPS) 및 MTLS(상호 TLS)는 엔드포인트 인증 및 IM 암호화를 사용하도록 설정합니다. 지점 간 오디오, 비디오 및 응용 프로그램 공유 스트림은 SRTP(Secure Real-Time Transport Protocol)를 사용하여 암호화되고 무결성을 확인합니다.
  • 가능한 경우 사용자 인증을 위한 업계 표준 프로토콜입니다.

이 섹션의 문서에서는 이러한 각 기본 요소가 SfBO 서비스의 보안을 강화하기 위해 어떻게 작동하는지 설명합니다.

Microsoft Entra ID

Microsoft Entra ID Microsoft 365 및 Office 365 대한 디렉터리 서비스로 작동합니다. 모든 사용자 디렉터리 정보 및 할당된 정책을 저장합니다.

SfBO용 공개 키 인프라

SfBO 서비스는 서버 인증을 위해 인증서를 사용하고 클라이언트와 서버 간에 그리고 서로 다른 서버 역할 간에 신뢰 체인을 설정합니다. Windows Server PKI(공개 키 인프라)는 이 신뢰 체인을 설정하고 유효성을 검사하기 위한 인프라를 제공합니다.

인증서는 디지털 ID입니다. 이름으로 서버를 식별하고 해당 속성을 지정합니다. 인증서에 대한 정보가 유효한지 확인하려면 클라이언트 또는 서버에 연결하는 다른 서버에서 신뢰할 수 있는 CA(인증 기관)에서 인증서를 발급해야 합니다. 서버가 프라이빗 네트워크의 다른 클라이언트 및 서버와만 연결하는 경우 CA는 엔터프라이즈 CA일 수 있습니다. 서버가 프라이빗 네트워크 외부의 엔터티와 상호 작용하는 경우 공용 CA가 필요할 수 있습니다.

인증서에 대한 정보가 유효한 경우에도 인증서를 표시하는 서버가 실제로 인증서로 표시되는 서버인지 확인하는 방법이 있어야 합니다. Windows PKI가 들어오는 위치입니다.

각 인증서는 공개 키에 연결됩니다. 인증서에 명명된 서버에는 알고 있는 해당 프라이빗 키만 포함됩니다. 연결 클라이언트 또는 서버는 공개 키를 사용하여 임의의 정보를 암호화하고 서버로 보냅니다. 서버가 정보를 암호 해독하고 일반 텍스트로 반환하는 경우 연결 엔터티는 서버가 인증서에 대한 프라이빗 키를 보유하므로 인증서에 이름이 지정된 서버인지 확인할 수 있습니다.

CRL 배포 지점

SfBO를 사용하려면 모든 서버 인증서에 하나 이상의 CRL(인증서 해지 목록) 배포 지점이 포함되어야 합니다. CRL 배포 지점(CDP)은 발급된 이후로 인증서가 해지되지 않았으며 인증서가 아직 유효 기간 내에 있는지 확인하기 위해 CRL을 다운로드할 수 있는 위치입니다. CRL 배포 지점은 인증서 속성에서 URL로 표시되고 안전한 HTTP입니다. SfBO 서비스는 모든 인증서 인증을 사용하여 CRL을 확인합니다.

확장된 키 사용

SfBO 서비스의 모든 구성 요소에는 서버 인증을 위해 EKU(향상된 키 사용)를 지원하기 위해 모든 서버 인증서가 필요합니다. 서버 인증을 위해 EKU 필드를 구성한다는 것은 인증서가 서버 인증에 유효함을 의미합니다. 이러한 EKU는 MTLS에 반드시 필요합니다.

SfBO용 TLS 및 MTLS

TLS 및 MTLS 프로토콜은 인터넷상에서 암호화된 통신 및 엔드포인트 인증을 제공합니다. SfBO는 이러한 두 프로토콜을 사용하여 신뢰할 수 있는 서버의 네트워크를 만들고 해당 네트워크를 통한 모든 통신이 암호화되도록 합니다. 서버 간의 모든 SIP 통신은 MTLS를 통해 발생합니다. 클라이언트에서 서버로의 SIP 통신은 TLS를 통해 발생합니다.

TLS를 사용하면 사용자가 클라이언트 소프트웨어를 통해 연결하는 SfBO 서버를 인증할 수 있습니다. TLS 연결에서 클라이언트는 서버에 유효한 인증서를 요청합니다. 유효하려면 클라이언트에서 신뢰할 수 있는 CA에서 인증서를 발급해야 하며 서버의 DNS 이름이 인증서의 DNS 이름과 일치해야 합니다. 인증서가 유효한 경우 클라이언트는 인증서의 공개 키를 사용하여 통신에 사용할 대칭 암호화 키를 암호화합니다. 따라서 인증서의 원래 소유자만이 개인 키를 사용하여 통신 내용을 복호화할 수 있습니다. 결과 연결은 신뢰할 수 있으며 해당 시점부터는 다른 신뢰할 수 있는 서버 또는 클라이언트에서 이의를 제기하지 않습니다. 이 컨텍스트 내에서 웹 서비스에 사용되는 SSL(Secure Sockets Layer)을 TLS 기반로 연결할 수 있습니다.

상호 인증을 위해 서버 간 연결에는 상호 TLS(MTLS)가 사용됩니다. MTLS 연결에서 메시지를 보낸 서버와 그것을 받는 서버는 상호 간에 신뢰할 수 있는CA에서 발급된 인증서를 교환합니다. 인증서는 각 서버의 ID를 상대방 서버에게 증명합니다. SfBO 서비스에서 이 절차를 따릅니다.

TLS 및 MTLS는 도청 및 중간자 공격을 모두 방지하는 데 도움이 됩니다. 맨 인 더 미들 공격에서 공격자는 두 네트워크 엔터티 간의 통신 경로를 두 당사자에 대한 지식 없이 공격자의 컴퓨터를 통해 다시 라우팅합니다. TLS 및 SfBO의 신뢰할 수 있는 서버 사양은 두 엔드포인트 간의 공개 키 암호화를 사용하여 조정된 엔드투엔드 암호화를 사용하여 애플리케이션 계층에서 맨인 더 중간 공격의 위험을 부분적으로 완화하며, 공격자는 해당 프라이빗 키와 함께 유효하고 신뢰할 수 있는 인증서를 가져야 하며 클라이언트가 통신 암호를 해독하기 위해 통신하는 서비스 이름에 발급되어야 합니다.

SfBO 암호화

SfBO는 TLS 및 MTLS를 사용하여 인스턴트 메시지를 암호화합니다. 서버 간의 모든 트래픽은 해당 트래픽이 내부 네트워크로 한정되는지, 아니면 내부 네트워크 경계를 벗어나는지 관계없이 MTLS를 요구합니다.

다음 표에는 SfBO에서 사용하는 프로토콜이 요약되어 있습니다.

표 3 - 트래픽 보호

트래픽 유형 로 썩은
S2S(서버 간) MTLS
클라이언트-서버 TLS
인스턴트 메시징 및 현재 상태 TLS(TLS에 대해 구성된 경우)
미디어의 오디오 및 비디오 및 데스크톱 공유 SRTP
데스크톱 공유(신호) TLS
웹 회의 TLS
모임 콘텐츠 다운로드, 주소록 다운로드, 메일 그룹 확장 HTTPS

미디어 암호화

미디어 트래픽은 RTP(Real-Time Transport Protocol) 트래픽에 기밀유지, 인증 및 재생 공격으로부터 보호 기능을 제공하는 RTP 프로필인 보안 RTP(SRTP)를 사용하여 암호화됩니다. SRTP는 안전한 난수 생성기를 사용하여 생성되고 신호 TLS 채널을 사용하여 교환되는 세션 키를 사용합니다. 또한 중재 서버와 내부 다음 홉 간에 양방향으로 흐르는 미디어도 SRTP를 사용하여 암호화됩니다.

SfBO는 TURN을 통해 미디어 릴레이에 대한 보안 액세스를 위해 사용자 이름/암호를 생성합니다. 미디어 릴레이는 TLS 보안 SIP 채널을 통해 사용자 이름/암호를 교환합니다.

FIPS

SfBO는 암호화 키 교환에 FIPS(연방 정보 처리 표준) 규격 알고리즘을 사용합니다.

사용자 및 클라이언트 인증

신뢰할 수 있는 사용자는 Microsoft 365 또는 Office 365 Microsoft Entra ID 자격 증명을 인증한 사용자입니다.

인증은 신뢰할 수 있는 서버 또는 서비스에 사용자 자격 증명을 제공하는 것입니다. SfBO는 사용자의 상태 위치에 따라 다음 인증 프로토콜을 사용합니다.

  • 최신 인증 은 클라이언트와 서버 통신을 위한 OAUTH 2.0의 Microsoft 구현입니다. 인증서 기반 인증, 다단계 인증 및 조건부 액세스와 같은 보안 기능을 사용할 수 있습니다. MA를 사용하려면 온라인 테넌트 및 클라이언트 모두를 MA에 사용하도록 설정해야 합니다. 2017년 5월 이후에 만든 SfBO 테넌트는 기본적으로 MA를 사용하도록 설정되어 있습니다. 이 시간 이전에 만든 테넌트인 경우 여기에 있는 지침에 따라 켭니다. 다음 클라이언트는 모두 MA를 지원합니다. 비즈니스용 Skype 2015 또는 2016 클라이언트, Mac의 비즈니스용 Skype, Lync 2013 클라이언트, 3PIP IP 전화, iOS 및 Android.
  • 조직 ID 는 최신 인증이 사용하도록 설정되지 않았거나 사용할 수 없는 경우에 사용됩니다.
  • 소위 익명 사용자에 대한 다이제스트 프로토콜입니다. 익명 사용자는 Active Directory 자격 증명을 인식하지 못했지만 온-프레미스 회의에 초대되어 유효한 회의 키를 보유한 외부 사용자입니다. 다이제스트 인증은 다른 클라이언트 상호 작용에 사용되지 않습니다.

SfBO 인증은 다음 두 단계로 구성됩니다.

  1. 클라이언트와 서버 간에 보안 연결이 설정됩니다.
  2. 클라이언트와 서버는 기존 보안 연결을 사용하여 보내는 메시지에 서명하고 받는 메시지를 확인합니다. 서버에서 인증을 사용하도록 설정하면 클라이언트의 인증되지 않은 메시지가 허용되지 않습니다.

사용자 신뢰는 사용자 ID 자체가 아니라 사용자로부터 시작된 각 메시지에 연결됩니다. 서버는 각 메시지에서 유효한 사용자 자격 증명을 확인합니다. 사용자 자격 증명이 유효한 경우 메시지는 첫 번째 서버에서 수신할 뿐만 아니라 SfBO의 다른 모든 서버에 의해 도전되지 않습니다.

페더레이션된 파트너가 발급한 유효한 자격 증명을 가진 사용자는 신뢰할 수 있지만 필요에 따라 추가 제약 조건으로 인해 내부 사용자에게 부여된 모든 권한 범위를 이용할 수 없습니다.

미디어 인증의 경우 ICE 및 TURN 프로토콜은 IETF TURN RFC에 설명된 다이제스트 챌린지도 사용합니다. 자세한 내용은 미디어 순회를 참조하세요.

클라이언트 인증서는 사용자가 SfBO에서 인증되는 다른 방법을 제공합니다. 사용자에게 사용자 이름과 암호를 제공하는 대신 암호화 문제를 resolve 데 필요한 인증서에 해당하는 인증서와 프라이빗 키가 있습니다.

Windows PowerShell 및 SfBO 관리 도구

SfBO에서 IT 관리자는 O365 관리 포털을 통해 또는 TRPS(테넌트 원격 PowerShell)를 사용하여 서비스를 관리할 수 있습니다. 테넌트 관리자는 최신 인증을 사용하여 TRPS에 대해 인증합니다.

인터넷 경계에서 SfBO에 대한 액세스 구성

SfBO가 제대로 작동하려면(사용자가 모임 등에 참가할 수 있음) 고객은 SfBO 클라우드의 서비스에 대한 아웃바운드 UDP 및 TCP 트래픽이 허용되도록 인터넷 액세스를 구성해야 합니다. 자세한 내용은 여기를 참조하세요. https://support.office.com/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2#bkmk_lyo

UDP 3478-3481 및 TCP 443

UDP 3478-3481 및 TCP 443 포트는 클라이언트가 A/V Edge 서비스에서 서비스를 요청하는 데 사용됩니다. 클라이언트는 이러한 두 포트를 사용하여 원격 당사자가 연결할 UDP 및 TCP 포트를 각각 할당합니다. A/V Edge 서비스에 액세스하려면 먼저 클라이언트가 SfBO 등록 기관에서 인증된 SIP 신호 세션을 설정하여 A/V Edge 서비스 인증 자격 증명을 가져와야 합니다. 이러한 값은 TLS로 보호되는 신호 채널을 통해 전송되며 사전 공격을 완화하기 위해 컴퓨터가 생성됩니다. 그런 다음 클라이언트는 A/V Edge 서비스에서 다이제스트 인증에 이러한 자격 증명을 사용하여 미디어 세션에서 사용할 포트를 할당할 수 있습니다. 초기 할당 요청은 클라이언트에서 전송되고 A/V Edge 서비스의 401 nonce/challenge 메시지로 응답됩니다. 클라이언트는 사용자 이름과 nonce의 HMAC(해시 메시지 인증 코드) 해시를 포함하는 두 번째 할당을 보냅니다.

재생 공격을 방지하기 위한 시퀀스 번호 메커니즘도 마련되어 있습니다. 서버는 사용자 이름 및 암호에 대한 자체 지식에 따라 예상 HMAC를 계산하고 HMAC 값이 일치하는 경우 할당 프로시저가 수행됩니다. 그렇지 않으면 패킷이 삭제됩니다. 이 호출 세션 내의 후속 메시지에도 동일한 HMAC 메커니즘이 적용됩니다. 이 사용자 이름/암호 값의 수명은 최대 8시간이며, 이 시간 동안 클라이언트는 후속 호출을 위해 새 사용자 이름/암호를 다시 입력합니다.

UDP/TCP 50,000–59,999

TCP 50,000 아웃바운드는 애플리케이션 및 데스크톱 공유, 파일 전송을 포함하여 SfBO에 사용됩니다. UDP/TCP 50,000-59,999 포트 범위는 A/V Edge 서비스에서 NAT/방화벽 순회 서비스가 필요한 Microsoft Office Communications Server 2007 파트너와의 미디어 세션에 사용됩니다. A/V Edge 서비스는 이러한 포트를 사용하는 유일한 프로세스이므로 포트 범위의 크기는 잠재적 공격 노출 영역을 나타내지 않습니다. 적절한 보안 방법은 불필요한 네트워크 서비스를 실행하지 않음으로써 수신 대기 포트의 총 수를 항상 최소화하는 것입니다. 네트워크 서비스가 실행되고 있지 않으면 원격 공격자가 네트워크 서비스를 악용할 수 없으며 호스트 컴퓨터의 공격 노출 영역이 줄어듭니다. 그러나 단일 서비스 내에서 포트 수를 줄이면 동일한 이점이 제공되지 않습니다. A/V Edge 서비스 소프트웨어는 10개와 마찬가지로 10,000개 포트가 열려 있는 공격에 더 이상 노출되지 않습니다. 이 범위 내의 포트 할당은 임의로 수행되며 현재 할당되지 않은 포트는 패킷을 수신 대기하지 않습니다.

외부 사용자 A/V 트래픽 순회

외부 사용자와 내부 사용자가 미디어를 교환할 수 있도록 하려면 Access Edge 서비스가 세션을 설정하고 중단하는 데 필요한 SIP 신호를 처리해야 합니다. 또한 미디어 전송을 위한 릴레이 역할을 하려면 A/V Edge 서비스가 필요합니다. 호출 시퀀스는 다음 그림에 나와 있습니다.

모임 참가의 통화 순서입니다.

  1. 사용자는 SfBO 모임에 참가하라는 초대가 포함된 이메일을 받습니다. 전자 메일에는 회의 키와 회의에 대한 HTTP 기반 URL 링크가 포함되어 있습니다. 키와 URL은 모두 특정 모임에 대해 고유합니다.

    사용자는 사용자의 컴퓨터에서 클라이언트 검색 프로세스를 시작하는 전자 메일의 모임 URL을 클릭하여 조인 절차를 시작합니다. 클라이언트가 검색되면 이 클라이언트가 시작됩니다. 검색되지 않으면 사용자가 웹 클라이언트로 리디렉션됩니다.

  2. SfBO 클라이언트는 사용자의 자격 증명이 포함된 SIP INVITE를 보냅니다. 페더레이션 또는 원격 사용자가 엔터프라이즈 자격 증명을 사용하여 회의에 참가합니다. 페더레이션된 사용자의 경우 SIP 초대는 먼저 사용자를 인증하고 초대를 SfBO에 전달하는 자신의 홈 서버로 전송됩니다. 다이제스트 인증을 통과하려면 익명 사용자가 필요합니다.

    SfBO는 원격 또는 익명 사용자를 인증하고 클라이언트에 알립니다. 2단계에서 설명한 것처럼 회의에 참가하는 페더레이션된 사용자는 엔터프라이즈에서 인증됩니다.

  3. 클라이언트는 INFO 요청을 보내 사용자를 A/V 회의에 추가합니다.

    A/V 회의는 다른 정보 중에서 A/V 회의 Edge 서비스에 표시할 토큰이 포함된 사용자 추가 응답을 보냅니다.

    [참고] 이전의 모든 SIP 트래픽은 Access Edge 서비스를 통해 전달되었습니다.

    클라이언트는 토큰의 유효성을 검사하고 다른 권한 부여 토큰이 포함된 요청을 내부 A/V 회의 서버에 프록시하는 A/V 회의 서버에 연결합니다. A/V 회의 서버는 원래 SIP 채널을 통해 발급한 권한 부여 토큰의 유효성을 검사하여 유효한 사용자가 회의에 참가하고 있는지 확인합니다.

  4. 클라이언트와 A/V 회의 서버 간에 미디어 연결이 협상되고 SRTP를 통해 설정됩니다.

  5. 사용자는 SfBO 모임에 참가하라는 초대가 포함된 이메일을 받습니다. 전자 메일에는 회의 키와 회의에 대한 HTTP 기반 URL 링크가 포함되어 있습니다. 키와 URL은 모두 특정 모임에 대해 고유합니다.

SfBO에 대한 페더레이션 보호

조직은 페더레이션을 사용하여 다른 조직과 통신하여 IM 및 현재 상태를 공유할 수 있습니다. SfBO 페더레이션은 기본적으로 설정됩니다. 그러나 테넌트 관리자는 Microsoft 365 또는 Office 365 관리자 포털을 통해 이를 제어할 수 있습니다. 자세한 내용을 참조하세요.

SfBO 컨퍼런스에 대한 위협 해결

SfBO는 엔터프라이즈 사용자가 실시간 웹 컨퍼런스를 만들고 참가할 수 있는 기능을 제공합니다. 엔터프라이즈 사용자는 Microsoft Entra ID, Microsoft 365 또는 Office 365 계정이 없는 외부 사용자를 이러한 모임에 참여하도록 초대할 수도 있습니다. 안전하고 인증된 ID를 가진 페더레이션 파트너에 의해 고용된 사용자는 모임에 참가할 수도 있으며, 이를 위해 승격된 경우 발표자 역할을 할 수 있습니다. 익명 사용자는 모임을 만들거나 발표자로서 모임에 참가할 수 없지만, 참가한 후에 발표자로 승격될 수 있습니다.

외부 사용자가 SfBO 모임에 참여할 수 있도록 하면 이 기능의 가치가 크게 증가하지만 일부 보안 위험도 수반됩니다. 이러한 위험을 해결하기 위해 SfBO는 다음과 같은 추가 안전 장치를 제공합니다.

  • 참가자 역할은 회의 제어 권한을 결정합니다.
  • 참가자 유형을 사용하여 특정 모임에 대한 액세스를 제한할 수 있습니다.
  • 정의된 모임 유형에 따라 참가할 수 있는 참가자 유형이 결정됩니다.
  • 회의 일정은 Microsoft Entra 계정 및 SfBO 라이선스가 있는 사용자로 제한됩니다.
  • 익명, 즉 인증되지 않은 사용자는 전화 접속 전화 회의에 참가하려는 사용자가 전화 회의 액세스 번호 중 하나에 참가한 다음 회의 ID를 입력하라는 메시지가 표시됩니다. 인증되지 않은 익명 사용자에게도 이름을 기록하라는 메시지가 표시됩니다. 기록된 이름은 회의에서 인증되지 않은 사용자를 식별합니다. 익명 사용자는 적어도 한 명의 리더 또는 인증된 사용자가 참가할 때까지 회의에 참가할 수 없으며 미리 정의된 역할을 할당할 수 없습니다.

참가자 역할

모임 참가자는 각각 고유한 사용 권한 및 제한이 있는 세 개의 그룹으로 분류됩니다.

  • 주최자 즉석에서, 또는 예약을 통해 모임을 만드는 사용자. 이끌이는 인증된 엔터프라이즈 사용자여야 하며 모임의 모든 최종 사용자 측면을 제어할 수 있습니다.
  • 발표자 지원되는 모든 미디어를 사용하여 모임에서 정보를 발표할 권한이 있는 사용자. 모임 주최자가 정의를 통해 발표자로 되거나 그 외 발표자가 될 수 있는 다른 사용자를 결정합니다. 주최자는 모임을 예약하거나 모임이 진행되는 동안 결정할 수 있습니다.
  • 참석자 모임에 참석하도록 초대되었지만 발표자 역할을 할 권한이 없는 사용자입니다.

발표자는 모임 도중에 참석자를 발표자 역할로 승격할 수도 있습니다.

참가자 유형

모임 참가자 또한 위치 및 자격 증명을 기준으로 분류됩니다. 이러한 특성을 모두 사용하여 특정 모임에 액세스할 수 있는 사용자를 지정할 수 있습니다. 사용자는 대략 다음 범주로 분류됩니다.

  1. 테넌트 에 속한 사용자 이러한 사용자는 테넌트의 Microsoft Entra ID 자격 증명을 가지고 있습니다.

    1. Corpnet 내부 – 이러한 사용자는 회사 네트워크 내부에서 조인합니다.
    2. 원격 사용자 - 이러한 사용자는 회사 네트워크 외부에서 참여합니다. 여기에는 가정에서, 또는 이동 중에 작업 하는 직원뿐만 아니라 신뢰할 수 있는 공급업체 직원과 같이 서비스 계약으로 엔터프라이즈 자격 증명을 허가 받은 다른 사용자도 포함될 수 있습니다. 원격 사용자는 회의를 만들고 참가하고 발표자 역할을 할 수 있습니다.

  2. 테넌트 에 속하지 않는 사용자 이러한 사용자는 테넌트의 Microsoft Entra ID 자격 증명이 없습니다.

    1. 페더레이션된 사용자 - 페더레이션된 사용자는 페더레이션된 파트너와 유효한 자격 증명을 보유하므로 SfBO에서 인증된 것으로 처리됩니다. 페더레이션된 사용자는 회의에 참가하고 모임에 참가한 후 발표자로 승격될 수 있지만 페더레이션된 기업에서는 컨퍼런스를 만들 수 없습니다.
    2. 익명 사용자 - 익명 사용자는 Active Directory ID가 없으며 테넌트와 페더레이션되지 않습니다.

고객 데이터에 따르면 많은 회의에 외부 사용자가 참여하는 것으로 표시됩니다. 또한 동일한 고객은 해당 사용자가 회의에 참가할 수 있도록 허용하기 전에 외부 사용자의 ID에 대한 확신을 원합니다. 다음 섹션에서 설명한 것처럼 SfBO는 명시적으로 허용된 사용자 유형에 대한 모임 액세스를 제한하며 모임에 참가할 때 모든 사용자 유형이 적절한 자격 증명을 제시하도록 요구합니다.

참가자 입장 허가

SfBO에서 익명 사용자는 대기실이라는 대기 영역으로 전송됩니다. 그런 다음 발표자는 이러한 사용자를 모임에 허용하거나 거부할 수 있습니다. 이러한 사용자는 로비로 전송되고, 리더는 알림을 받고, 사용자는 리더가 수락하거나 거부하거나 연결 시간이 초과될 때까지 기다립니다. 로비에 있는 동안 사용자는 음악을 듣습니다.

기본적으로 PSTN에서 전화를 거는 참가자는 모임으로 직접 이동하지만 전화 접속 참가자가 로비로 이동하도록 이 옵션을 변경할 수 있습니다.
모임 주최자는 참가자가 대기실에서 대기하지 않고 바로 모임에 참석 가능한지 여부를 제어합니다. 각 모임은 다음 방법 중 하나를 사용하여 액세스를 허용하도록 설정할 수 있습니다.

  • 나만, 모임 이끌이 이끌이를 제외한 모든 사람은 입장할 때까지 로비에서 기다려야 합니다.
  • 사람 회사의 모든 사용자가 초대받지 않은 경우에도 직접 모임에 참가할 수 있습니다.
  • 내 organization Microsoft 365 또는 Office 365 테넌트의 모든 SfBO 사용자는 메일 그룹에 없는 경우에도 로비에서 기다리지 않고 모임에 참가할 수 있습니다. 모든 외부 및 익명 사용자를 포함한 다른 모든 사용자는 인정될 때까지 로비에서 기다려야 합니다.
  • 누군가 모임 링크에 액세스할 수 있는 모든 사용자(제한 없음)는 모임에 직접 로그인합니다. 이끌이만(잠긴)을 제외한 모든 메서드를 지정하면 모임 이끌이가 로비를 우회하여 전화 접속을 사람 지정할 수도 있습니다.

발표자 기능

모임 주최자는 참가자가 모임 도중에 발표 가능한지 여부를 제어합니다. 각 모임의 발표자가 다음으로 제한되도록 설정할 수 있습니다.

  • 이끌이만 모임 이끌이만 프레젠테이션할 수 있습니다.
  • 내 회사에서 사람 모든 내부 사용자가 제시 할 수 있습니다.
  • 회사 외부의 사람들을 포함한 모든 사람 모임에 참가하는 모든 사용자(제한 없음)가 참석할 수 있습니다.
  • 사람 모임 이끌이는 발표자 목록에 추가하여 프레젠테이션할 수 있는 사용자를 지정합니다.

Microsoft 보안 센터