보안 및 Microsoft Teams
중요
Teams 서비스는 고객 경험 개선을 위해 변경될 수 있습니다. 예를 들어, 기본 액세스 또는 새로 고침 토큰 만료 시간은 Teams를 사용하는 성능 및 인증 복원을 향상시키기 위해 수정될 수 있습니다. 그러한 변경 사항은 원칙적으로 Teams를 안전하고 신뢰할 수 있는 상태로 유지하는 것을 목표로 수행됩니다.
Microsoft 365 및 Office 365 서비스의 일부인 Microsoft Teams는 심층 방어를 통한 서비스 수준 보안, 서비스 내의 고객 컨트롤, 보안 강화 및 운영 모범 사례 같은 모든 보안 모범 사례 및 절차를 준수합니다. 자세한 내용은 Microsoft 보안 센터를 참조하세요.
신뢰할 수 있는 설계
Teams는 Microsoft 신뢰할 수 있는 컴퓨팅 SDL(Security Development Lifecycle)에 따라 설계 및 개발되었으며, 거기에 대해서는 Microsoft SDL(Security Development Lifecycle)에 자세히 설명되어 있습니다. 더욱 안전한 통합 커뮤니케이션 시스템을 만드는 첫 단계는 위협 모델을 설계하고 각 기능이 설계된 대로 작동하는지 테스트하는 것이었습니다. 보안과 관련하여 향상된 여러 기능이 코딩 프로세스 및 사례에 기본 제공되었습니다. 빌드 시간에 도구는 코드가 최종 제품에 체크 인되기 전에 버퍼 오버런 및 기타 잠재적인 보안 위협을 검색합니다. 알려지지 않은 모든 보안 위협에 대해 설계하는 것은 불가능합니다. 시스템에서 완전한 보안을 보장할 수는 없습니다. 그러나 Teams는 제품 개발 초기부터 안전한 설계 원칙을 수용했기 때문에 업계의 표준 보안 기술을 아키텍처의 기본적인 요소로 포함합니다.
기본적으로 신뢰할 수 있음
Teams의 네트워크 통신은 기본적으로 암호화됩니다. 모든 서버가 인증서를 사용하도록 요구하고 OAUTH, TLS(전송 계층 보안) 및 SRTP(보안 실시간 전송 프로토콜)를 사용하여 모든 Teams 데이터가 네트워크에서 보호됩니다.
Teams에서 공통 보안 위협을 처리하는 방법
이 섹션에서는 Teams 서비스의 보안에 대한 보다 일반적인 위협과 Microsoft에서 각 위협을 완화하는 방법을 알아봅니다.
노출된 키 공격
Teams는 Windows Server 운영 체제의 PKI 기능을 사용하여 TLS 연결을 위한 암호화에 사용되는 키 데이터를 보호합니다. 미디어 암호화에 사용되는 키는 TLS 연결을 통해 교환됩니다.
네트워크 서비스 거부 공격
분산 서비스 거부(DDOS) 공격은 공격자가 유효한 사용자의 정상적인 네트워크 사용 및 작동을 막을 때 발생합니다. 공격자가 서비스 거부(DoS) 공격을 사용하여 수행할 수 있는 작업은 다음과 같습니다.
- 공격하는 네트워크에서 실행되는 응용 프로그램 및 서비스에 유효하지 않은 데이터를 보내정상적인 작동을 막습니다.
- 많은 양의 트래픽을 보내서 시스템이 정당한 요청에 응답하지 않거나 느리게 응답할 때까지 시스템에 과부하가 걸리게 합니다.
- 공격의 증거를 숨깁니다.
- 사용자가 네트워크 리소스에 액세스하지 못하게 막습니다.
Teams는 Azure DDOS 네트워크 보호를 실행하고 동일한 엔드포인트, 서브넷 및 페더레이션 엔터티의 클라이언트 요청을 제한하여 이러한 공격을 방해합니다.
도청
도청은 공격자가 네트워크의 데이터 경로에 액세스하고 트래픽을 모니터링하고 읽을 수 있는 능력이 있을 때 발생합니다. 도청은 스니핑(sniffing) 또는 스누핑(snooping)이라고도 합니다. 일반 텍스트 트래픽의 경우 공격자가 경로에 대한 액세스 권한을 얻으면 그러한 트래픽을 읽을 수 있습니다. 예를 들어 데이터 경로에 있는 라우터를 제어하여 공격을 수행합니다.
Teams는 MTLS(상호 TLS) 및 S2S(서버 간) OAuth(다른 프로토콜 포함)를 사용하여 Microsoft 365 및 Office 365 내의 서버 통신을 수행하고 클라이언트에서 서비스로 TLS를 사용합니다. 네트워크의 모든 트래픽이 암호화됩니다.
이러한 통신 방법은 단일 대화 시간 내에 도청하기가 어렵거나 불가능하게 합니다. TLS는 모든 당사자를 인증하고 모든 트래픽을 암호화합니다. TLS가 도청을 방지하지는 않지만 공격자는 암호화가 깨지지 않는 한 트래픽을 읽을 수 없습니다.
TURN(NAT 주변의 릴레이를 사용한 탐색) 프로토콜은 실시간 미디어 용도로 사용됩니다. TURN 프로토콜은 트래픽 암호화를 요구하지 않으며 전송하는 정보는 메시지 무결성으로 보호됩니다. 도청에 열려 있지만 패킷의 원본 및 대상 주소를 보고 전송 정보(즉, IP 주소 및 포트)를 직접 추출할 수 있습니다. Teams 서비스는 절대로 일반 텍스트로 전송되지 않는 TURN 암호를 비롯한 몇 개의 항목에서 파생된 키를 사용하여 메시지가 유효한지 검사하는 식으로 데이터 유효성을 확인합니다. 미디어 트래픽에 SRTP가 사용되고 또한 암호화됩니다.
ID 스푸핑(IP 주소 스푸핑)
스푸핑은 공격자가 승인 없이 네트워크, 컴퓨터 또는 네트워크 구성 요소의 IP 주소를 식별한 다음 사용할 때 발생합니다. 공격이 성공하면 공격자가 IP 주소를 통해 일반적으로 식별되는 엔터티인 것처럼 작업할 수 있습니다.
TLS는 모든 당사자를 인증하고 모든 트래픽을 암호화합니다. TLS를 사용하면 공격자가 특정 연결에 대해 IP 주소 스푸핑을 수행하는 것을 방지합니다(예: 상호 TLS 연결). 공격자는 여전히 DNS(Domain Name System) 서버의 주소를 스푸핑할 수 있습니다. 그러나 Teams의 인증은 인증서를 사용하여 수행되므로 공격자는 통신에 참여하는 당사자 중 하나를 스푸핑할 때 필요한 유효한 정보를 보유하지 못합니다.
중간자(man-in-the-middle) 공격
공격자가 통신 중인 두 사용자에 대한 정보가 없어도 공격자 컴퓨터를 통해 두 사용자 간의 통신을 다시 라우팅하는 경우 가로채기(Man-in-the-Middle) 공격이 발생합니다. 공격자는 지정 수신인에게 전송하기에 앞서 트래픽을 모니터링하고 읽을 수 있습니다. 통신의 각 사용자는 모르고 공격자와 트래픽을 주고 받는 동시에 지정 사용자하고만 통신하고 있다고 생각합니다. 이 시나리오는 공격자가 Active Directory 도메인 서비스를 수정하여 서버를 신뢰할 수 있는 서버로 추가하거나 DNS 구성을 수정하거나 다른 방법을 사용하여 클라이언트가 서버로 가는 도중에 공격자를 통해 연결하도록 할 수 있는 경우에 발생할 수 있습니다.
SRTP(Secure Real-Time Transport Protocol)를 사용하여 미디어 스트림을 암호화하면 Teams 오디오, 비디오, 응용 프로그램 공유에 참여하는 두 엔드포인트 간의 미디어 트래픽에 대한 중간자(man-in-the-middle) 공격이 방지됩니다. 암호화 키는 TLS 1.2 및 AES-256(GCM 모드) 암호화 UDP 또는 TCP 채널을 사용하는 독점 신호 프로토콜(Teams Call Signaling 프로토콜)을 통해 두 엔드포인트 간에 협상됩니다.
실시간 전송 프로토콜(RTP) 리플레이 공격
재생 공격은 두 당사자 같의 유효한 미디어 전송이 중간에 가로채여서 악의적인 목적으로 다시 전송될 때 발생합니다. Teams는 수신기가 이미 수신된 RTP 패킷의 인덱스를 유지하고 각각의 새 패킷을 인덱스에 이미 나열된 패킷과 비교할 수 있도록 하여 재생 공격으로부터 전송을 보호하는 보안 신호 프로토콜과 함께 SRTP를 사용합니다.
스핌
스핌은 인스턴트 메시지 형식을 띠는 것을 제외하면 스팸과 같이 원치 않는 상업적인 인스턴트 메시지 또는 현재 상태 구독 요청입니다. 그 자체로 네트워크가 손상되는 것은 아니지만 최소한 성가신 일이며 리소스 가용성과 생산을 감소시킬 수 있으며 네트워크 손상으로 이어질 수 있습니다. 사용자 간에 서로 요청을 보내어 스핌하는 것을 예로 들 수 있습니다. 사용자는 서로를 차단하여 스핌을 방지할 수 있지만 페더레이션을 사용하면 악의적인 행위자가 조직적 스핌 공격을 설정하면 파트너에서 페더레이션을 비활성화하지 않는 한 극복하기 어려울 수 있습니다.
바이러스 및 웜
바이러스는 유사한 코드 단위를 더 많이 재생산하는 것을 목적으로 하는 코드 단위입니다. 바이러스가 작동하기 위해서는 파일, 전자 메일 또는 프로그램 같은 호스트가 필요합니다. 바이러스와 마찬가지로 웜은 유사한 코드 단위를 더 많이 복제하지만 바이러스와 달리 호스트가 필요하지 않은 코드 단위입니다. 바이러스와 웜은 주로 클라이언트 간 파일 전송 도중이나 다른 사용자로부터 URL이 전송될 때에 나타납니다. 컴퓨터에 바이러스가 있는 경우 예를 들어 사용자의 ID를 사용하여 사용자 대신 인스턴트 메시지를 보낼 수 있습니다. 주기적으로 바이러스를 검사하는 등의 표준 클라이언트 보안 모범 사례를 통해 이 문제를 완화시킬 수 있습니다.
피싱 시도
Teams의 피싱 공격은 비용이 많이 들고 안심할 수 있습니다. 이러한 공격은 가짜 웹 사이트 링크 및 무해한 것처럼 보이지만 클릭 시 위험한 소프트웨어를 다운로드 할 수있는 첨부 파일을 통해 암호, 코드, 신용 카드 번호 및 기타 중요한 정보와 같은 정보를 공개하는 사용자를 속여 작동합니다. 이러한 공격의 대부분은 사용자를 대상으로 하므로 액세스 권한이 많은 높은 대상도 만연할 수 있습니다. 그러나 Teams 관리자와 사용자 모두에 대한 피싱 방지 전략이 있습니다.
organization 사용자가 외부 보낸 사람으로부터 피싱 메시지를 받은 경우 테넌트 관리자는 그래프 API 'RemoveAllAccessForUser'를 사용하여 사용자의 보기에서 이 메시지를 제거할 수 있습니다.
Teams용 보안 프레임워크
Teams는 제로 트러스트 같은 보안 아이디어와 최소 권한 액세스 원칙을 보증합니다. 이 섹션에서는 Microsoft Teams의 보안 프레임워크를 구성하는 기본 요소를 간략하게 살펴보겠습니다.
핵심 요소는 다음과 같습니다.
- 사용자 계정에 대해 신뢰할 수 있는 단일 백 엔드 리포지토리를 제공하는 Microsoft Entra ID입니다. 사용자 프로필 정보는 Microsoft Graph의 작업을 통해 Microsoft Entra ID에 저장됩니다.
- 네트워크 트래픽을 추적할 때 볼 수 있는 여러 토큰이 발행될 수 있습니다. 채팅 및 오디오 트래픽을 볼 때 추적에서 볼 수 있는 Skype 토큰을 포함합니다.
- TLS(전송 계층 보안)는 이동 중인 채널을 암호화합니다. 인증은 인증서에 따라 MTLS(상호 TLS) 또는 Microsoft Entra ID에 따라 서비스 간 인증을 사용하여 이루어집니다.
- 지점 간 오디오, 비디오 및 응용 프로그램 공유 스트림은 SRTP(Secure Real-Time Transport Protocol)를 사용하여 암호화되고 무결성을 확인합니다.
- 예를 들어 게시물에서 파일로 이동하기 위해 Teams에서 탭 간에 전환하는 동안 특히 토큰 교환 및 권한 협상과 관련된 추적에서 OAuth 트래픽을 볼 수 있습니다. 탭에 대한 OAuth 흐름의 예는 이 문서를 참조하세요.
- Teams는 가능하면 사용자 인증에 산업 표준 프로토콜을 사용합니다.
다음 섹션에서는 이 중 몇 가지 핵심 기술을 살펴보겠습니다.
Microsoft Entra ID
Microsoft Entra ID는 Microsoft 365 및 Office 365 대한 디렉터리 서비스로 작동합니다. 모든 사용자 및 응용 프로그램 디렉터리 정보 및 정책 할당을 저장합니다.
Teams의 트래픽 암호화
이 테이블에는 주요 트래픽 유형과 암호화에 사용되는 프로토콜이 표시됩니다.
| 트래픽 유형 | 암호화 방법 |
|---|---|
| S2S(서버 간) | TLS(MTLS 또는 서비스 간 OAuth 사용) |
| 클라이언트-서버(예: 인스턴트 메시징 및 현재 상태) | TLS |
| 미디어 흐름(예: 미디어의 오디오 및 비디오 공유) | TLS |
| 미디어의 오디오 및 비디오 공유 | SRTP/TLS |
| 신호 | TLS |
| 클라이언트 간 향상된 암호화(예: 엔드 투 엔드 암호화 호출) | SRTP/DTLS |
CRL(인증서 해지 목록) 배포 지점
Microsoft 365 및 Office 365 트래픽은 TLS/HTTPS 암호화 채널을 통해서 이루어지므로, 인증서가 모든 트래픽을 암호화하는 데 사용됩니다. 팀은 모든 서버 인증서에 하나 이상의 CRL 배포 지점을 포함해야 합니다. CRL 배포 지점(CDP)은 발급된 이후로 인증서가 해지되지 않았으며 인증서가 아직 유효 기간 내에 있는지 확인하기 위해 CRL을 다운로드할 수 있는 위치입니다. CRL 배포 지점은 인증서 속성에서 URL로 표시되고 안전한 HTTP입니다. Teams 서비스는 모든 인증서 인증에서 CRL을 확인 합니다.
확장된 키 사용
Teams 서비스의 모든 구성 요소는 서버 인증을 위해 모든 서버 인증서가 EKU(Enhanced Key Usage)를 지원해야 합니다. 서버 인증을 위해 EKU 필드를 구성한다는 것은 인증서가 서버 인증에 유효함을 의미합니다. 이러한 EKU는 MTLS에 반드시 필요합니다.
Teams용 TLS
Teams 데이터는 Microsoft 서비스, 서비스 간, 클라이언트와 서비스 간에 전송 중이거나 사용하지 않을 때 암호화됩니다. Microsoft는 TLS 및 SRTP와 같은 업계 표준 기술을 사용하여 전송 중인 모든 데이터를 암호화합니다. 전송 중인 데이터에는 메시지, 파일, 모임 및 기타 콘텐츠가 포함됩니다. 엔터프라이즈 데이터는 또한 Microsoft 서비스에서 암호화되어 있으므로 조직에서 필요한 경우 콘텐츠를 해독하여 eDiscovery와 같은 방법으로 보안 및 규정 준수 의무를 충족할 수 있습니다. Microsoft 365의 암호화에 대한 자세한 내용은 Microsoft 365의 암호화를 참조하세요.
TCP 데이터 흐름은 TLS를 사용하여 암호화되며 MTLS 및 서비스 간 OAuth 프로토콜은 서비스, 시스템 및 클라이언트 간 엔드포인트 인증 통신을 제공합니다. Teams는 이러한 프로토콜을 사용하여 신뢰할 수 있는 시스템 네트워크를 만들고 해당 네트워크를 통한 모든 통신이 암호화되도록 합니다.
TLS 연결에서 클라이언트는 서버에 유효한 인증서를 요청합니다. 인증서가 유효하려면 클라이언트가 신뢰하는 인증 기관(CA)에서 발급된 것이라야 하고 서버의 DNS 이름이 인증서에 있는 DNS 이름과 일치해야 합니다. 인증서가 유효한 경우 클라이언트는 인증서의 공개 키를 사용하여 통신에 사용할 대칭 암호화 키를 암호화합니다. 따라서 인증서의 원래 소유자만이 개인 키를 사용하여 통신 내용을 복호화할 수 있습니다. 그 지점으로부터 시작된 연결은 신뢰할 수 있으며 다른 신뢰할 수 있는 서버나 클라이언트에서 검사하지 않습니다.
TLS를 사용하면 도청 및 중간자(man-in-the-middle) 공격을 모두 방지하는 데 도움이 됩니다. 중간자 공격의 공격자는 당사자에 대한 정보가 없어도 공격자의 컴퓨터를 통해 두 네트워크 엔터티 간의 통신을 다시 라우팅합니다. 신뢰할 수 있는 서버의 TLS와 Teams 사양은 두 끝점 사이의 공개 키 암호기법을 사용하여 조정되는 암호화를 사용해 일부 응용 프로그램 계층의 중간자 공격 위험을 줄일 수 있습니다. 공격자는 개인 키에 맞는 올바르고 신뢰할 수 있는 인증서를 보유해야 하며 클라이언트가 해독하고자 통신하는 서비스명으로 발급받아야 합니다.
Teams 및 Microsoft 365 암호화
Microsoft 365 내에는 여러 암호화 계층이 있습니다. Teams의 암호화는 나머지 Microsoft 365 암호화와 함께 작동하여 조직의 콘텐츠를 보호합니다. 이 문서에서는 Teams와 관련된 암호화 기술에 대해 설명합니다. Microsoft 365의 암호화 개요는 Microsoft 365의 암호화를 참조하세요.
미디어 암호화
Teams의 통화 흐름은 HTTPS를 통한 세션 설명 프로토콜(SDP) RFC 8866 제안 및 응답 모델을 기반으로 합니다. 수신자가 수신 전화를 수락하면 발신자와 수신자가 세션 매개 변수에 동의합니다.
미디어 트래픽은 RTP 트래픽에 대한 기밀성, 인증 및 재생 공격 보호를 제공하는 RTP(실시간 전송 프로토콜)의 프로필인 SRTP(보안 RTP)를 사용하여 발신자와 수신자 간에 암호화되고 흐릅니다. SRTP는 보안 난수 생성기에 의해 생성되고 시그널링 TLS 채널을 사용하여 교환되는 세션 키를 사용합니다. 대부분의 경우 클라이언트에서 클라이언트로의 미디어 트래픽은 클라이언트에서 서버로의 연결 신호를 통해 협상되며 클라이언트에서 클라이언트로 직접 이동할 때 SRTP를 사용하여 암호화됩니다.
일반적인 통화 흐름에서 암호화 키 협상은 통화 신호 채널을 통해 발생합니다. 종단 간 암호화 통화에서 신호 흐름은 일반 일대일 Teams 통화와 동일합니다. 그러나 Teams는 DTLS를 사용하여 두 클라이언트 끝점에서 생성된 호출별 인증서를 기반으로 암호화 키를 파생합니다. DTLS는 클라이언트 인증서를 기반으로 키를 파생하므로 키는 Microsoft에 불투명합니다. 두 클라이언트가 키에 동의하면 미디어는 SRTP를 통해 이 DTLS 협상 암호화 키를 사용하여 흐르기 시작합니다.
발신자와 수신자 간의 메시지 가로채기 공격으로부터 보호하기 위해 Teams는 발신자와 수신자의 엔드포인트 호출 인증서의 SHA-256 지문에서 20자리 보안 코드를 도출합니다. 발신자와 수신자는 20자리 보안 코드를 서로 읽어서 일치하는지 확인할 수 있습니다. 코드가 일치하지 않으면 발신자와 수신자 간의 연결이 메시지 가로채기 공격에 의해 가로채어진 것입니다. 통화가 손상된 경우 사용자는 수동으로 통화를 종료할 수 있습니다.
Teams는 TURN을 통한 미디어 릴레이로의 보안되는 액세스를 위해 자격 증명 기반의 토큰을 사용합니다. 미디어 릴레이는 TLS 보안 채널을 통해 토큰을 교환합니다.
연방 정보 처리 표준(FIPS)
Teams는 암호화 키 교환에 FIPS 호환 알고리즘을 사용합니다. FIPS 구현에 대한 자세한 내용은 연방 정보 처리 표준(FIPS) 간행물 140-2를 참조하세요.
사용자 및 클라이언트 인증
신뢰할 수 있는 사용자는 Microsoft 365 또는 Office 365 Microsoft Entra ID로 자격 증명을 인증한 사용자입니다.
인증은 신뢰할 수 있는 서버 또는 서비스에 사용자 자격 증명을 제공하는 것입니다. Teams는 사용자의 상태 및 위치에 따라 다음 인증 프로토콜을 사용합니다.
- 최신 인증(MA)은 클라이언트-서버 통신을 위한 OAUTH 2.0의 Microsoft 구현입니다. 다단계 인증 및 조건부 액세스와 같은 보안 기능을 활성화합니다. MA를 사용하려면 온라인 테넌트와 클라이언트 모두 MA에 대해 활성화해야 합니다. PC와 모바일의 Teams 클라이언트와 웹 클라이언트는 모두 MA를 지원합니다.
참고
Microsoft Entra 인증 및 권한 부여 방법에 대한 자세한 내용을 보려면 이 문서의 소개 및 'Microsoft Entra ID의 인증 기본 사항' 섹션이 도움이 됩니다.
Teams 인증은 Microsoft Entra ID 및 OAuth를 통해 수행됩니다. 인증 프로세스는 다음으로 간소화할 수 있습니다.
- 사용자 로그인 > 토큰 발급 > 다음 요청은 발급된 토큰을 사용합니다.
클라이언트에서 서버로의 요청은 OAuth를 사용하여 Microsoft Entra ID에 의해 인증되고 권한이 부여됩니다. 페더레이션 파트너가 발급한 유효한 자격 증명이 있는 사용자는 신뢰할 수 있으며 기본 사용자와 동일한 프로세스를 통과합니다. 그러나 관리자가 추가 제한을 설정할 수 있습니다.
미디어 인증의 경우 ICE 및 TURN 프로토콜은 IETF TURN RFC에 설명된 다이제스트 챌린지도 사용합니다.
Windows PowerShell 및 Teams 관리 도구
Teams에서 IT 관리자는 Microsoft 365 관리 센터를 통해 또는 TRPS(테넌트 원격 PowerShell)를 사용하여 서비스를 관리할 수 있습니다. 테넌트 관리자는 최신 인증을 사용하여 TRPS에 대해 인증합니다.
인터넷 경계에서 Teams에 대한 액세스 구성
예를 들어 사용자가 모임에 참가할 수 있도록 Teams가 제대로 작동하려면 고객은 Teams 클라우드의 서비스에 대한 아웃바운드 UDP 및 TCP 트래픽이 허용되도록 인터넷 액세스를 구성해야 합니다. 자세한 내용은 Office 365 URL 및 IP 주소 범위를 참조하세요.
UDP 3478-3481 및 TCP 443
UDP 3478-3481 및 TCP 443 포트는 클라이언트에서 오디오 및 비디오 자료에 대한 서비스를 요청하는 데 사용 됩니다. 클라이언트는 이 두 포트를 사용하여 이러한 미디어 흐름이 가능하도록 UDP 및 TCP 포트를 각각 할당합니다. 이러한 포트를 통한 미디어 흐름은 TLS로 보호 되는 신호 채널을 통해 교환되는 키를 사용하여 보호됩니다.
Teams용 페더레이션 보호 조치
조직은 페더레이션을 사용하여 다른 조직과 통신하여 IM 및 현재 상태를 공유할 수 있습니다. Teams의 경우 기본적으로 페더레이션이 설정되어 있습니다. 그러나 테넌트 관리자는 Microsoft 365 관리 센터 통해 페더레이션을 제어할 수 있습니다.
Teams 모임에 대한 위협 해결
엔터프라이즈 사용자는 실시간 모임을 만들고 참가하고 Microsoft Entra ID, Microsoft 365 또는 Office 365 계정이 없는 외부 사용자를 초대하여 이러한 모임에 참여할 수 있습니다.
외부 사용자가 Teams 모임에 참여하도록 하는 것은 유용할 수 있지만 일부 보안 위험도 발생할 수 있습니다. 이러한 위험을 해결하기 위해 Teams는 다음과 같은 안전 장치를 사용합니다.
모임 전:
모임에 참가할 수 있는 외부 참가자 유형을 결정합니다.
익명 액세스를 사용하면 팀에 로그인되지 않은 (1) 인증되지 않은 사용자(일반적으로 브라우저에서 모임 링크를 통해 참가) 및 (2) 이끌이 및 조직과의 외부 액세스 권한이 설정되지 않은 외부 테넌트의 인증된 사용자의 모임 참가를 허용합니다.
외부 액세스를 통해 더 많은 권한으로 모임에 참가할 수 있는 인증된 외부 사용자 및 조직을 결정할 수 있습니다. 이러한 사용자는 신뢰할 수 있는 조직에 속한 것으로 간주됩니다.
게스트 액세스를 사용하면 조직 외부의 사용자가 회사 데이터에 대한 제어를 유지하면서 팀, 채널의 문서, 리소스, 채팅 및 애플리케이션에 액세스할 수 있는 게스트 계정을 만들 수 있습니다.
참고
조직과 외부 액세스 권한이 없는 사용자 및 조직은 익명으로 간주됩니다. 익명 참가를 차단한 경우 모임에 참가할 수 없습니다.
외부 액세스를 양방향으로 사용하도록 설정해야 하며, 두 조직 모두 상호 외부 액세스를 허용해야 합니다.
참고
Teams의 게스트 및 외부 액세스에 대한 자세한 내용은 이 문서를 참조하세요. 문서에서는 게스트 또는 외부 사용자가 Teams에 로그인 할 때 보고 사용할 수 있는 기능에 대해 다룹니다.
모임에 직접 참가할 수 있는 사용자와 발표자 모임 역할이 있는 이끌이, 공동 이끌이 또는 인증된 사용자가 허용되기 위해 로비에서 기다려야 하는 사용자를 결정합니다.
익명 사용자 및 전화 접속 발신자가 조직의 사용자, 신뢰할 수 있는 조직의 사용자 및 게스트 액세스 권한이 있는 사용자가 통화에 참가하기 전에 모임을 시작할 수 있는지 여부를 결정합니다.
참고
모임 예약은 조직에서 인증된 사용자 또는 조직에 게스트 액세스 권한이 있는 사용자로 제한됩니다.
모임 중:
- 특정 참가자 모임 역할을 할당하여 모임 제어 권한을 결정합니다. 모임 참가자는 각각 고유한 권한과 제한이 있는 그룹으로 나며 , 여기에 설명되어 있습니다.
참고
모임을 녹음/녹화하는 동안 콘텐츠에 액세스하는 데 사용되는 권한 매트릭스를 보려면 이 문서와 매트릭스를 참조하세요.
모임이 실행되는 동안 수정:
- 모임이 진행되는 동안 모임 옵션을 수정할 수 있습니다. 변경 내용이 저장되면 실행 중인 모임에서 몇 초 내에 눈에 띄게 됩니다. 이후의 모임에도 마찬가지로 효력을 미칩니다. 이러한 역할을 할당하는 방법에 대한 자세한 내용은 이 문서를 참조하세요.
참고
Teams 관리자 설정의 변경은 최대 24시간이 걸릴 수 있습니다.
관련 항목
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기