CTI API 보안: 임의 발신·통화 제어·도청 위험을 막는 방법

1장 CTI API는 일반적인 업무 API와 다르다#

보통 API라고 하면 고객정보 조회나 데이터 저장 기능을 먼저 떠올릴 수 있습니다.

하지만 CTI API는 다릅니다.

CTI는 실제 전화 시스템을 제어할 수 있기 때문입니다.

예를 들어 CTI를 이용하면 상담원 화면에서:

발신
응답
보류
통화 재개
호 전환
3자 통화
종료

같은 동작을 실행할 수 있습니다.

원본 자료에서도 CTI의 주요 제어 기능으로 Click-to-Call, Answer, Hold/Retrieve, Transfer, Conference, Hangup을 제시합니다.

즉 CTI API에 대한 접근 권한을 얻었다는 것은 단순히 데이터를 읽을 수 있다는 의미가 아니라 실제 전화 기능을 움직일 가능성이 있다는 의미입니다.

2장 CTI API 보안이 중요한 이유#

원본 자료에서는 CTI 명령을 인증된 세션에서만 허용해야 한다고 명확하게 설명합니다.

또한 임의 단말에서:

발신
녹음
전환

등을 실행할 수 없도록 권한과 세션 관리가 필요하다고 설명합니다.

그리고 CTI API가 외부에 노출될 경우:

통화 도청·임의 발신 위험

이 있으므로:

인증·암호화·권한 통제

가 필수라고 경고합니다.

3장 가장 위험한 구조는 무엇인가#

가장 단순하게 잘못 설계된 구조를 생각해보겠습니다.

외부 사용자
 ↓
CTI API
 ↓
PBX
 ↓
전화 발신

만약 CTI API가 누구의 요청인지 확인하지 않고 번호만 전달받아 발신한다면 문제가 됩니다.

예를 들어:

POST /call
{
  "number": "01012345678"
}

같은 요청만으로 실제 전화가 걸린다면 권한이 없는 사용자가 시스템을 악용할 수 있습니다.

원본에서도 이러한 임의 발신 위험을 직접 경고하고 있습니다.

4장 CTI API에서 가장 먼저 확인해야 하는 것은 인증이다#

인증 Authentication은 요청한 사용자가 누구인지 확인하는 과정입니다.

예를 들어:

요청
 ↓
사용자 인증
 ↓
상담원 확인
 ↓
CTI 명령 처리

구조가 필요합니다.

인증되지 않은 사용자가 CTI API를 호출할 수 있다면 발신이나 통화 제어 같은 기능이 노출될 수 있습니다.

원본 CTI 문서에서도 인증된 세션에서만 CTI 명령을 허용하도록 요구합니다.

5장 인증과 인가는 다른 개념이다#

두 용어는 자주 혼동됩니다.

인증#

누구인가

인가#

무엇을 할 수 있는가

예를 들어 상담원 A가 정상적으로 로그인했다고 하겠습니다.

인증은 성공했습니다.

하지만 그렇다고 상담원 A가:

관리자 단말 제어
다른 상담원 통화 전환
전체 녹취 접근

까지 허용되어야 하는 것은 아닙니다.

즉:

인증 성공
≠
모든 기능 사용 가능

입니다.

6장 권한 통제가 중요한 이유#

원본은 CTI API에 대해 권한 통제가 필수라고 명확히 설명합니다.

예를 들어 상담원 A에게 다음 권한만 필요하다고 하겠습니다.

자신의 전화 받기
자신의 통화 보류
자신의 통화 전환
자신의 통화 종료

그런데 시스템이 다음까지 허용하면 문제가 됩니다.

다른 상담원 단말 발신
다른 상담원 통화 종료
임의 녹음 제어

따라서 권한은 최소한으로 제한해야 합니다.

7장 상담원과 단말을 정확하게 연결해야 한다#

CTI 서버에서는 일반적으로 상담원과 단말의 관계를 관리합니다.

예:

상담원 A
 ↓
내선 2101

상담원 B
 ↓
내선 2102

CTI API에서 상담원 A가 요청을 보냈다면 기본적으로 A에게 허용된 단말만 제어하도록 제한하는 구조가 필요합니다.

원본 자료에서도 임의 단말로 발신·녹음·전환이 가능하지 않도록 권한·세션 관리가 필요하다고 설명합니다.

8장 세션 관리란 무엇인가#

상담원이 로그인한 뒤 CTI를 사용할 때는 하나의 세션이 만들어질 수 있습니다.

개념적으로는:

사용자 로그인
 ↓
상담원 세션
 ↓
CTI 연결
 ↓
허용된 단말
 ↓
통화 제어

입니다.

세션은:

누가 로그인했는지
어떤 상담원인지
어느 단말을 사용하는지
어떤 권한을 가지고 있는지

를 연결하는 중요한 기준이 됩니다.

9장 세션이 탈취되면 왜 위험한가#

CTI 명령이 세션에 기반한다면 해당 세션이 탈취되었을 때 공격자가 정상 상담원처럼 동작할 가능성을 고려해야 합니다.

예를 들어:

정상 상담원 세션
 ↓
공격자 탈취
 ↓
CTI API 호출
 ↓
발신 / 전환 / 종료 시도

같은 위험을 생각할 수 있습니다.

원본은 세션 탈취 시나리오 자체를 상세히 설명하지는 않지만 CTI 명령을 인증된 세션에서만 허용하고 세션 관리가 필요하다고 명시합니다.

10장 세션 타임아웃이 필요한 이유#

원본 SSO 자료에서는 상담원 환경에서 세션 타임아웃을 고려해야 한다고 설명합니다.

예를 들어 상담원이 자리를 떠났는데 로그인 세션이 계속 유지된다면 다른 사람이 해당 PC에서 CTI 기능을 사용할 수 있습니다.

따라서 일정 시간 활동이 없으면 세션을 만료시키는 정책을 사용할 수 있습니다.

11장 자동 락이 필요한 이유#

원본 SSO 자료에서는 상담원 환경 고려사항으로 자동 락, 자리비움 잠금도 제시합니다.

상담원이 잠시 자리를 비웠을 때:

로그인 유지
+
CTI 제어 가능

상태라면 위험할 수 있습니다.

따라서 화면 잠금이나 재인증 정책을 적용할 수 있습니다.

12장 SSO란 무엇인가#

SSO는 Single Sign-On의 약자입니다.

한 번의 인증으로 여러 시스템에 접근할 수 있도록 하는 구조입니다.

원본에서는 상담원이 하나의 인증으로:

등 여러 시스템에 접근할 수 있다고 설명합니다.

콜센터처럼 여러 시스템을 동시에 사용하는 환경에서는 SSO가 운영 편의성을 높일 수 있습니다.

13장 원본에서 제시하는 SSO 방식#

원본 자료에서는 다음 방식들을 제시합니다.

방식	원본의 설명
SAML 2.0	엔터프라이즈·레거시
OIDC	모던·모바일 친화적
OAuth 2.0 + JWT	API·B2B

다만 실제 CTI 제품이 어떤 방식을 지원하는지는 제품별로 확인해야 합니다.

14장 SSO를 쓰면 보안이 자동으로 해결되는가#

아닙니다.

SSO는 인증을 통합하는 방법입니다.

하지만 CTI 보안에는 여전히:

권한
세션
단말 매핑
API 암호화
감사로그

등이 필요합니다.

즉:

SSO
= 로그인 통합

CTI 보안
= 인증 + 인가 + 세션 + 암호화 + 감사

로 보는 것이 좋습니다.

15장 CTI API를 외부에 직접 노출하면 왜 위험한가#

원본은 CTI API가 외부에 노출될 경우 통화 도청과 임의 발신 위험이 있다고 경고합니다.

예를 들어 다음과 같은 구조보다:

Internet
 ↓
CTI API
 ↓
PBX

중간에 접근 제어 계층을 두는 구조를 고려할 수 있습니다.

외부 시스템
 ↓
인증 / 접근 통제
 ↓
API Gateway
 ↓
CTI API
 ↓
PBX

원본의 API Gateway 자료에서도 인증·인가와 트래픽 제어를 핵심 역할로 제시합니다.

16장 API Gateway는 어떤 역할을 할까#

원본에서는 API Gateway 역할을 다음과 같이 설명합니다.

인증·인가
트래픽 제어
로깅
모니터링
메트릭
프로토콜 변환

인증·인가 방식의 예로:

OAuth 2.0
JWT
mTLS

도 제시합니다.

CTI API를 외부 또는 여러 업무 시스템과 연결해야 한다면 이런 중간 계층을 통해 접근을 통제하는 구조를 검토할 수 있습니다.

17장 API Gateway가 CTI 자체를 대신하는 것은 아니다#

역할을 구분해야 합니다.

API Gateway#

API 접근과 인증·트래픽·로그 관리

CTI#

전화 이벤트와 전화 제어

PBX#

실제 전화 처리

즉:

외부 시스템
 ↓
API Gateway
 ↓
CTI
 ↓
PBX

처럼 각각 다른 역할을 담당합니다.

18장 OAuth 2.0은 어디에 사용할 수 있을까#

원본에서는 API Gateway 인증·인가 예로 OAuth 2.0을 제시합니다.

OAuth 2.0 기반 구조에서는 API를 호출하는 클라이언트에게 적절한 접근 권한을 부여하는 방식으로 활용할 수 있습니다.

다만 원본은 CTI 전용 OAuth Scope 설계나 구체적인 토큰 정책까지는 제시하지 않습니다.

따라서 실제 적용 시에는 CTI 제품과 인증 시스템 구조에 맞춰 설계해야 합니다.

19장 JWT란 무엇인가#

원본은 API Gateway와 SSO 자료에서 JWT를 언급합니다.

JWT는 인증이나 권한 정보를 전달하는 데 사용할 수 있는 토큰 형식입니다.

CTI API에서 사용한다면 개념적으로:

사용자 로그인
 ↓
토큰 발급
 ↓
API 호출
 ↓
토큰 검증
 ↓
권한 확인
 ↓
CTI 명령

같은 흐름을 구성할 수 있습니다.

구체적인 JWT 필드나 만료 정책은 원본에 포함되어 있지 않습니다.

20장 mTLS란 무엇인가#

원본 API Gateway 자료에서는 인증·인가 방식의 예로 mTLS도 제시합니다.

mTLS는 서버만 인증하는 일반 TLS보다 양쪽 시스템이 서로 인증하는 구조에 사용할 수 있습니다.

특히 시스템 대 시스템 통신에서 상대 시스템이 신뢰할 수 있는 대상인지 확인하는 데 활용할 수 있습니다.

다만 원본은 CTI 적용 방식까지 구체적으로 설명하지 않습니다.

21장 암호화는 왜 필요한가#

원본은 CTI API가 외부로 노출될 경우 암호화가 필수라고 설명합니다.

전화 제어 명령이나 세션 정보가 암호화되지 않은 상태로 전달된다면 중간에서 정보가 노출될 위험이 커질 수 있습니다.

따라서 CTI API 통신도 보호된 채널을 사용해야 합니다.

22장 콜시스템 보안에서 전송 암호화#

원본 콜시스템 보안 문서에서는 전송 영역의 보안 기술로 다음을 제시합니다.

TLS
SRTP
mTLS

여기서 역할을 단순하게 구분하면:

TLS·mTLS#

주로 제어·데이터 통신 보호에 활용

SRTP#

음성 미디어 보호에 활용

할 수 있습니다.

구체적인 적용 여부는 사용하는 콜시스템과 미디어 구조에 따라 달라집니다.

23장 CTI API 암호화와 음성 암호화는 같은 것이 아니다#

CTI API를 HTTPS나 TLS로 보호한다고 해서 음성 미디어까지 자동으로 암호화되는 것은 아닙니다.

개념적으로:

CTI 제어 신호
→ TLS 등의 보호

음성 미디어
→ SRTP 등의 보호

처럼 서로 다른 영역이 있을 수 있습니다.

원본 보안 자료에서도 전송 보안 기술로 TLS·SRTP·mTLS를 각각 제시합니다.

24장 도청 위험은 어디에서 생길 수 있을까#

원본 CTI 자료에서는 CTI API 외부 노출 시 통화 도청 위험을 직접 언급합니다.

또 콜시스템 보안 문서는 내부자에 의한 녹취·데이터 유출도 위협 모델에 포함합니다.

즉 음성이나 녹취에 접근할 수 있는 기능은 특히 강하게 통제해야 합니다.

25장 녹음 권한은 일반 통화 제어와 분리할 필요가 있다#

원본에서는 임의 단말로 녹음이 가능하지 않도록 권한 관리가 필요하다고 설명합니다.

즉 상담원이 전화 받기 권한을 가지고 있다고 해서 반드시 모든 녹음 제어 권한까지 가져야 하는 것은 아닙니다.

권한을 기능별로 나누는 방식이 필요할 수 있습니다.

예:

상담원
- Answer
- Hold
- Transfer

관리자
- 상담원 기능
- 녹취 조회
- 추가 관리 기능

구체적인 역할 체계는 조직 정책에 따라 달라집니다.

26장 RBAC란 무엇인가#

원본 콜시스템 보안 자료에서는 애플리케이션 인가 방식으로 RBAC를 제시합니다.

RBAC는 Role-Based Access Control의 약자로 사용자의 역할에 따라 권한을 부여하는 방식입니다.

예를 들어:

상담원
 ↓
일반 통화 제어

팀장
 ↓
추가 모니터링 기능

관리자
 ↓
시스템 관리

처럼 역할별 권한을 구성할 수 있습니다.

원본은 구체적인 역할 예시까지 제공하지 않으므로 위 구조는 설명을 위한 예시입니다.

27장 최소 권한 원칙이 중요한 이유#

CTI에서 필요 이상의 권한을 주면 사고 범위가 커질 수 있습니다.

예를 들어 상담원이 실제 업무에 필요한 기능이:

Answer
Hold
Transfer
Hangup

뿐이라면 모든 CTI 관리 API나 다른 상담원의 단말 제어 권한까지 줄 필요는 없습니다.

즉 사용자가 업무에 필요한 범위만 사용할 수 있도록 제한하는 것이 중요합니다.

원본의 권한 통제와 RBAC 개념도 이러한 구조와 연결됩니다.

28장 임의 발신을 어떻게 막을까#

원본은 임의 발신을 대표적인 CTI 위험으로 제시합니다.

개념적으로 다음과 같은 검증이 필요할 수 있습니다.

발신 요청
 ↓
사용자 인증
 ↓
세션 확인
 ↓
상담원 확인
 ↓
단말 권한 확인
 ↓
발신 권한 확인
 ↓
CTI 명령 처리

단순히 전화번호만 넘기면 발신되는 구조보다 여러 단계의 권한 확인이 필요합니다.

29장 PBX의 발신 권한도 함께 적용될 수 있다#

CTI에서 발신 명령을 허용하더라도 PBX 자체의 발신 정책이 별도로 존재할 수 있습니다.

예를 들어:

외부 발신 제한
국제전화 제한
특정 번호 발신 제한

같은 정책입니다.

즉 CTI 권한과 PBX 권한을 서로 다른 보호 계층으로 생각할 수 있습니다.

원본의 핵심은 임의 발신을 허용하지 말아야 한다는 것입니다.

30장 Transfer 권한도 통제해야 한다#

Transfer는 통화를 다른 대상에게 넘기는 기능입니다.

만약 아무 상담원이나 임의 내선 또는 허용되지 않은 대상으로 통화를 전환할 수 있다면 운영상 문제가 될 수 있습니다.

원본에서도 임의 단말로 전환이 가능하지 않도록 권한 관리가 필요하다고 설명합니다.

31장 API 호출 횟수도 통제해야 할까#

원본 API Gateway 문서에서는 스로틀링과 레이트 리미팅을 주요 역할로 제시합니다.

이는 짧은 시간에 과도한 API 요청이 들어오는 상황을 제어하는 데 사용할 수 있습니다.

CTI API처럼 실제 전화 시스템을 움직이는 기능에서는 과도한 요청이 운영에 영향을 줄 수 있으므로 접근 제어 계층에서 트래픽 관리가 중요할 수 있습니다.

32장 레이트 리미팅이란 무엇인가#

레이트 리미팅은 일정 시간 동안 허용할 API 요청 수를 제한하는 방식입니다.

예를 들어 개념적으로:

정상 호출
→ 허용

과도한 반복 호출
→ 제한

형태입니다.

원본은 구체적인 초당 요청 수나 제한 값까지는 제시하지 않습니다.

33장 중복 요청도 문제다#

상담원이 발신 버튼을 빠르게 여러 번 누르거나 네트워크 재시도 때문에 동일한 명령이 반복될 수 있습니다.

원본 API 설계 가이드에서는 Idempotency-Key 등 멱등성 지원을 제시합니다.

멱등성은 같은 요청이 반복되더라도 의도하지 않은 중복 처리가 발생하지 않도록 설계하는 개념입니다.

CTI 발신처럼 실제 동작이 발생하는 API에서는 특히 검토할 가치가 있습니다.

34장 Webhook도 검증이 필요하다#

원본 API Gateway 자료에서는 Webhook에 대해:

재시도
서명 검증
멱등성 처리

가 중요하다고 설명합니다.

콜시스템 이벤트를 외부 시스템으로 Webhook 방식으로 전달한다면 단순히 HTTP 요청이 들어왔다는 이유만으로 신뢰해서는 안 됩니다.

요청이 실제 신뢰된 시스템에서 왔는지를 검증해야 합니다.

35장 로그가 필요한 이유#

CTI는 실제 전화 제어를 수행할 수 있기 때문에 누가 어떤 동작을 실행했는지 추적하는 것이 중요합니다.

원본 API Gateway 자료에서는 로깅·모니터링·메트릭을 핵심 역할로 제시합니다.

또 보안 문서에서는 접근 로그와 변경 로그를 감사 영역으로 제시합니다.

36장 어떤 정보를 로그로 추적할 수 있을까#

원본은 CTI 전용 로그 필드까지는 제시하지 않습니다.

다만 구조적으로는 다음과 같은 정보를 추적할 수 있습니다.

요청 사용자
 ↓
상담원 ID
 ↓
대상 단말
 ↓
실행한 명령
 ↓
처리 결과

이런 기록이 있어야 장애나 이상 동작이 발생했을 때 원인을 확인하기 쉽습니다.

37장 감사로그란 무엇인가#

감사로그는 단순 개발 디버깅용 로그와 목적이 다릅니다.

누가:

언제
어떤 시스템에 접근했고
어떤 기능을 사용했으며
무엇을 변경했는지

추적하는 데 사용됩니다.

원본 보안 자료에서도 접근 로그·변경 로그·WORM을 감사 영역의 요소로 제시합니다.

38장 관리자 권한도 기록해야 한다#

보안 사고는 외부 공격만으로 발생하는 것이 아닙니다.

원본 보안 자료에서는 위협 모델에 내부자에 의한 녹취·데이터 유출도 포함합니다.

따라서 관리자나 높은 권한을 가진 사용자도 예외 없이 접근과 변경 기록을 남기는 것이 중요합니다.

39장 API 인증 실패도 모니터링해야 한다#

인증 실패가 반복되면 단순 사용자 실수일 수도 있지만 비정상적인 접근 시도일 가능성도 있습니다.

원본은 구체적인 탐지 규칙까지는 제시하지 않지만 API Gateway 역할에:

인증·인가
로깅
모니터링
메트릭

을 함께 제시합니다.

따라서 인증 실패와 권한 거부 같은 이벤트도 모니터링 대상이 될 수 있습니다.

40장 CTI API는 내부망이면 안전할까#

내부망에 있다는 이유만으로 모든 요청을 신뢰하면 안 됩니다.

원본 보안 문서에서도 위협 모델로:

내부자에 의한 녹취·데이터 유출

을 제시합니다.

따라서 내부 시스템이라도:

인증
인가
접근 통제
감사로그

가 필요합니다.

41장 외주·협력사 접근도 고려해야 한다#

원본 콜시스템 보안 자료에서는 위협 모델로 소프트웨어·외주 협력사 침투를 제시합니다.

콜센터 시스템은 유지보수를 위해 외부 업체가 접근하는 경우가 있을 수 있습니다.

이때도 필요한 범위 이상으로 CTI API나 관리자 권한을 제공하지 않는 것이 중요합니다.

42장 API 인증이 약하면 데이터도 노출될 수 있다#

원본 보안 문서에서는:

API 인증 미흡으로 인한 데이터 노출

도 위협 모델에 포함합니다.

CTI 연동에서는 전화 상태뿐 아니라 CRM 고객정보와 연결될 수 있기 때문에 API 인증 문제는 전화 제어뿐 아니라 고객 데이터 보안 문제로 이어질 수 있습니다.

43장 네트워크 보안도 함께 봐야 한다#

원본 콜시스템 보안 자료에서는 네트워크 보안 요소로 다음을 제시합니다.

방화벽
SBC
IDS/IPS
VPN

즉 CTI API 보안은 애플리케이션 로그인만으로 끝나지 않습니다.

네트워크 접근 경로 자체도 통제해야 합니다.

44장 외부 시스템이 CTI를 호출해야 한다면#

외부 업무시스템과 CTI를 연동해야 하는 상황도 있을 수 있습니다.

이 경우 직접 CTI 내부 기능 전체를 공개하기보다는 필요한 기능만 API 형태로 노출하는 구조를 고려할 수 있습니다.

개념적으로:

외부 업무시스템
 ↓
API Gateway
 ↓
인증·인가
 ↓
허용된 API
 ↓
CTI

입니다.

원본 API Gateway 자료의 인증·인가, 트래픽 제어, 로깅 구조가 이러한 연동 계층에 활용될 수 있습니다.

45장 CTI API 권한을 기능별로 나누면#

원본은 구체적인 권한 모델까지는 제시하지 않지만 RBAC와 권한 통제 개념을 바탕으로 다음처럼 생각할 수 있습니다.

CALL_ANSWER
CALL_HOLD
CALL_TRANSFER
CALL_CONFERENCE
CALL_HANGUP
CALL_OUTBOUND
RECORDING_ACCESS

모든 사용자에게 전체 기능을 주는 것보다 필요한 기능만 부여하는 방식입니다.

이는 원본의 권한 통제 원칙을 설명하기 위한 확장 예시입니다.

46장 사용자별 권한뿐 아니라 단말 범위도 중요하다#

같은 Transfer 권한이 있어도:

어느 통화를 제어할 수 있는가?

가 중요합니다.

예를 들어 상담원 A는 자신의 단말과 자신의 현재 통화만 제어할 수 있도록 제한할 수 있습니다.

상담원 A
 ↓
2101 단말만 허용

원본에서도 임의 단말에 대한 발신·녹음·전환을 막아야 한다고 설명합니다.

47장 관리자 기능은 더 강하게 통제해야 한다#

관리자는 일반 상담원보다 넓은 권한을 가질 수 있습니다.

따라서 관리자 계정이 탈취되거나 오용되면 영향도 커질 수 있습니다.

원본 보안 문서에서는 애플리케이션 영역의 보안으로:

SSO/MFA
RBAC

를 제시합니다.

즉 권한이 높은 계정일수록 인증과 접근통제를 강화하는 것이 중요합니다.

48장 MFA란 무엇인가#

원본 보안 자료에서는 애플리케이션 인증 방식의 예로 SSO/MFA를 제시합니다.

MFA는 Multi-Factor Authentication으로 하나의 비밀번호만이 아니라 추가 인증 요소를 사용하는 방식입니다.

특히 관리자나 고권한 계정에서 추가 보호 수단으로 활용할 수 있습니다.

49장 보안과 상담원 UX 사이의 균형#

콜센터 상담원은 업무 중 빠르게 통화를 처리해야 합니다.

원본 SSO 자료에서도 상담원 환경은 빠른 로그인·로그아웃이 반복되며 자동 락·세션 타임아웃·단축키 UX가 운영 효율에 직결된다고 설명합니다.

따라서 보안을 강화한다고 매 통화마다 지나치게 복잡한 인증 절차를 요구하면 상담 효율이 떨어질 수 있습니다.

핵심은:

강한 인증

과

현실적인 상담 업무 흐름

을 함께 설계하는 것입니다.

50장 CTI API 보안 구조를 한 번에 보면#

전체 구조를 단순화하면 다음과 같습니다.

상담원 / 외부 시스템
 ↓
인증
 ↓
세션 확인
 ↓
권한 확인
 ↓
API Gateway
 ↓
CTI API
 ↓
상담원·단말 매핑 확인
 ↓
PBX
 ↓
전화 제어

그리고 전체 과정은:

접근 로그
명령 로그
처리 결과

로 추적할 수 있어야 합니다.

51장 안전한 CTI API의 핵심 질문#

CTI API를 설계하거나 점검할 때 다음 질문을 확인할 수 있습니다.

누가 요청했는가#

인증

이 사용자가 이 기능을 사용할 수 있는가#

인가

이 사용자가 이 단말을 제어할 수 있는가#

단말 권한

세션은 정상인가#

세션 관리

통신은 암호화되어 있는가#

전송 보호

너무 많은 요청이 들어오고 있지 않은가#

레이트 리미팅

누가 무엇을 실행했는지 기록되는가#

감사로그

이 질문들이 CTI API 보안의 기본 틀입니다.

52장 특히 피해야 할 구조#

다음과 같은 구조는 보안상 문제가 될 가능성이 큽니다.

인증 없는 CTI API#

누구나 호출
→ 전화 발신

모든 상담원에게 전체 단말 제어 허용#

상담원 A
→ 모든 내선 제어

외부에 CTI API 직접 노출#

Internet
→ CTI

로그 없는 전화 제어#

누가 발신·전환·종료했는지 확인 불가능

세션이 무기한 유지#

자리비움 이후에도 계속 통화 제어 가능

원본의 인증·권한·세션·암호화 원칙에 비춰보면 이러한 구조는 피해야 합니다.

53장 CTI API 보안을 한 문장으로 설명하면#

가장 쉽게 설명하면 다음과 같습니다.

CTI API 보안은 인증된 상담원이 자신에게 허용된 단말과 통화에 대해서만 필요한 전화 제어 기능을 사용할 수 있도록 제한하고, 모든 통신과 행위를 보호·기록하는 구조다.

더 짧게 표현하면:

누가, 어느 단말에서, 어떤 통화를, 어디까지 제어할 수 있는지를 통제하는 것이 CTI 보안의 핵심

입니다.

CTI API 보안 FAQ#

CTI API가 왜 위험할 수 있는가#

실제 전화 발신·전환·종료·녹음 같은 기능을 제어할 수 있기 때문입니다.

CTI 명령은 누구나 실행할 수 있는가#

아닙니다. 원본에서는 인증된 세션에서만 CTI 명령을 허용해야 한다고 설명합니다.

CTI API 외부 노출 시 어떤 위험이 있는가#

원본에서는 통화 도청과 임의 발신 위험을 경고합니다.

CTI API 보안에서 가장 중요한 요소는 무엇인가#

원본에서는 인증·암호화·권한 통제를 필수 요소로 제시합니다.

세션 관리가 왜 필요한가#

어떤 상담원이 어떤 단말을 사용하고 있는지 확인하고 임의 단말 제어를 막기 위해 필요합니다.

SSO를 사용할 수 있는가#

원본에서는 CRM·CTI·IVR 등을 하나의 인증으로 접근하는 SSO 구조를 제시합니다.

어떤 SSO 방식이 있는가#

원본에서는 SAML 2.0, OIDC, OAuth 2.0 + JWT를 제시합니다.

API Gateway는 어떤 역할을 하는가#

원본에서는 인증·인가, 트래픽 제어, 로깅, 모니터링, 메트릭, 프로토콜 변환 역할을 제시합니다.

API 호출 횟수도 제한해야 하는가#

원본 API Gateway 자료에서는 스로틀링과 레이트 리미팅을 주요 역할로 제시합니다.

CTI API 통신도 암호화해야 하는가#

네. 원본에서는 CTI API 외부 노출 시 암호화가 필수라고 설명합니다.

내부망이라면 인증이 없어도 되는가#

원본 보안 자료에서는 내부자에 의한 녹취·데이터 유출도 위협 모델로 제시합니다. 따라서 내부망에서도 인증·권한·감사 통제가 중요합니다.

RBAC란 무엇인가#

역할 기반 접근제어입니다. 원본 보안 자료에서는 애플리케이션 인가 방식으로 RBAC를 제시합니다.

감사로그가 왜 필요한가#

누가 언제 어떤 CTI 기능을 사용했는지 추적하기 위해 필요합니다. 원본에서는 접근 로그·변경 로그를 감사 영역으로 제시합니다.

핵심 정리#

CTI API는 단순 데이터 조회 API가 아니라 실제 전화 시스템을 제어할 수 있는 API입니다.

원본에서는 CTI API 보안과 관련해 다음 내용을 명확하게 제시합니다.

CTI 명령은 인증된 세션에서만 허용

임의 단말 발신·녹음·전환 방지

권한·세션 관리 필요

또한 외부 노출 시:

통화 도청

임의 발신

위험이 있으므로:

인증

암호화

권한 통제

가 필수라고 설명합니다.

API 연동 계층에서는 원본의 API Gateway 자료에 따라 다음 기능을 함께 고려할 수 있습니다.

OAuth 2.0·JWT·mTLS 기반 인증·인가
스로틀링·레이트 리미팅
로깅·모니터링·메트릭
Webhook 서명 검증과 멱등성 처리

또 상담원 인증 환경에서는 SAML 2.0, OIDC, OAuth 2.0 + JWT 같은 SSO 방식과 자동 락·세션 타임아웃을 고려할 수 있습니다.

가장 짧게 정리하면 다음과 같습니다.

CTI 보안의 핵심은 인증된 사용자가 자신에게 허용된 단말과 통화만 필요한 범위에서 제어하도록 제한하고, 그 모든 과정을 암호화하고 기록하는 것이다.