“인터넷 트래픽의 90% 이상” M2M 상호작용 관리 설계 5계명

사용자에게 인간적인 면이 없고 개성도 찾기 어렵다는 느낌이 든다면, 그럴 만한 이유가 있을 것이다. 사용자가 기계라면 그럴 수 있다. 오늘날 인터넷 트래픽의 90% 이상은 기계 간 트래픽이다. 실제로 B2B SaaS 애플리케이션을 사용하는 기계도 종류만 다를 뿐이지 엄연히 사용자다. 따라서 온라인 및 SaaS 애플리케이션은 기계 간(M2M) 상호작용의 다양한 과제와 요구사항을 처리하도록 사용자 관리 체계와 정책을 신중하게 설계해야 한다.
 

오랜 기간 B2B SaaS 기업에서 M2M 상호작용 관련 업무를 도운 경험을 바탕으로 효율적이고 효과적이고 안전한 기계 간 사용자 관리를 위한 모범 사례를 정리했다. 하나씩 살펴보자. 
 

M2M 사용자 및 각각의 사용 사례 파악 

인간 사용자 관리에서도 컨텍스트가 중요할 수 있지만 기계의 경우 더 중요하다. 기계 사용자는 자신의 상태, 상황 및 의도에 대해 사람보다 훨씬 더 적은 정보만 제공하기 때문이다. 많은 경우 기계 사용자는 하나 또는 소수의 서비스에만 액세스하는 반면 인간 사용자는 훨씬 더 많은 서비스에 액세스한다. 

기계 간 상호작용에는 브라우저 에이전트, MAC, NIC 주소, 지리 데이터와 같은 유용한 단서가 포함되지 않는다. 일반적으로 사용되는 프로토콜의 API 호출인 경우가 많고 여기에는 최소한의 식별 정보만 포함된다. 기계 사용자의 서비스 요청에 대한 컨텍스트에 따라 정책을 적용하고 사용자 관리를 설계하는 방식을 결정해야 한다. 

M2M 사용자 관리에서 모든 서비스는 다른 서비스와 어떻게 통신할 수 있는지, 그리고 어느 서비스와 통신해야 하는지를 알아야 한다. 모든 서비스는 다른 서비스와 통신하는 방법과 액세스할 권한이 필요한 대상 핵심 서비스를 알아야 한다. API 게이트웨이와 서비스 메시가 이러한 기능을 일부 제공할 수 있지만 이 둘은 사용자 중심의 접근 방식이 아니다(M2M 사용자라 해도 마찬가지). 
 

다중 요소 인증 없는 보안 

MFA는 오늘날 인간 사용자의 보안 검증 프로세스에서 중요한 부분이지만 기계 사용자는 MFA를 사용할 수 없다. 또한 기계는 인간보다 훨씬 더 빠른 속도로 상호작용이 가능하므로 M2M 트랜잭션은 보통 밀리초 단위로 이뤄진다. 이로 인해 새로운 공격 표면이 형성되고, 실제로 많은 사이버 범죄자가 API 공격을 통해 이를 노리고 있다. M2M 상호작용을 대상으로 사용자 관리 프로세스를 실행하는 섹데브옵스(SecDevOps) 관점에서 이는 IP 주소 제한, 요청 속도 제한, 인증서 또는 키 순환, 그리고 이상적으로는 사람 또는 기계가 생성한, 이상 사용 패턴을 인식하는 정책과 같은 다른 보안 메커니즘에 훨씬 더 세심하게 주의를 기울여야 함을 의미한다. 
 

내부 기계 사용자와 외부 기계 사용자 

요청의 진원지가 내부 기계인지 또는 외부 사용자인지에 따라 보안 고려 사항도 크게 달라진다. 내부 요청으로, 쿠버네티스 클러스터 내에서 한 서비스에서 다른 서비스로 가는 요청이라면 인증은 내부적으로 적용되며 대체로 비교적 가볍게 처리된다. 예를 들어 서비스 메시는 특정 내부 서비스가 연결할 수 있는 서비스에 대한 정책을 설정하는 데 사용된다. 많은 조직이 내부의 기계 간 상호작용을 여전히 인증하지 않고 있지만 CISO 및 위험 관리팀은 모든 곳에 기본 인증을 구현하기 위해 노력하고 있다. 

현재까지 많은 플랫폼 운영 및 섹데브옵스 팀은 내부 보안에 단순한 인증 방법인 공유 비밀 번호를 사용하고 있다. 단순한 인증에는 위반 또는 노출된 비밀 번호를 손쉽게 대체하기 위한 강력한 프로세스가 필요하다. 이 비밀 번호 교체 프로세스가 없으면 새로운 비밀 번호를 생성해 공유하는 동안 조직은 다운타임 위험에 노출된다. 규모가 큰 경우 이중, 삼중으로 연결된 기계 사용자 전반을 동기화해야 하는 비밀 번호 변경은 상당히 부담스러운 작업이 된다. 따라서 내부 M2M 통신이라 해도 기술적인 어려움은 있다. 

외부 M2M 통신 및 기계 사용자 관리의 경우 훨씬 더 복잡하다. 비밀 번호 공유는 보안이 불충분하다. 이를 설명하기 위해 사용자 서비스와 이메일 서비스, 두 개의 서비스가 있다고 가정해 보자. 사용자에게 이메일을 보내려고 한다. 모든 사용자가 이메일을 보낼 권한을 갖고 있지는 않다. 따라서 사용자를 적절히 관리하기 위해서 애플리케이션은 어느 사용자에게 이메일 권한이 있는지, 그 사용자에게 보내는 메시지임을 어느 이메일에 표시해야 하는지를 인식해야 한다. 지금의 세계에서 비밀은 쉽게 무너진다. 
 

JWT 대 액세스 토큰 대 클라이언트 자격 증명 

이 사용 사례 역시 M2M JSON 웹 토큰(JWT)이 일반 M2M 통신 서비스보다 더 선호되는 이유를 보여준다. 사용자 관리 서비스는 특정 사용자 또는 특정 조직에 대한 토큰을 생성해야 한다. 토큰은 폐기하거나 특정 간격에 따라 갱신이 필요하도록 설정할 수 있다. 

토큰 수명 주기 정책과 운영 시스템을 잘 설계하면 보안 및 사용자 관리 서비스에서 운영 중단 없이 신속하게 액세스를 폐기하거나 키를 순환할 수 있다. 정책은 인증 철회 또는 갱신 목록을 통해 자동으로 적용된다. 갱신 간격이 비교적 짧은 경우 사용자 관리를 조정해서 M2M 사용자에게 제로 트러스트에 가까운 보안을 제공할 수 있다. JWT는 여러 속성을 포함할 수 있으므로 인코딩 컨텍스트에서 특히 유용하다. 

기업이 외부 인증을 처리하는 두 번째 방법은 사용자가 하나의 값 문자열을 수신하는 액세스 토큰을 통한 방법이다. 액세스 토큰의 작동 방식은 다음과 같다. 
 

1. 클라이언트가 권한 부여 서버에 요청하면서 클라이언트 비밀, 클라이언트 ID, 요청 서비스 및 범위를 보낸다. 
2. 권한 부여 서버는 요청을 검증하고 액세스 토큰과 함께 응답을 보낸다. 
3. 클라이언트는 액세스 토큰을 적용해서 관련 서비스 엔드포인트로부터 보호되는 리소스를 요청한다(API). 

액세스 토큰은 간단한 트랜잭션에는 매우 효과적이지만 복잡한 시나리오에서는 제대로 작동하지 않아 단일 실패 지점을 일으킬 수 있다. 예를 들어 어떤 이유로 액세스 토큰이 검증되지 않을 경우 쉽게 의지할 수 있는 대안이나 신뢰를 평가할 다른 메커니즘이 없다. 마이크로서비스 아키텍처에서 실행 중이라면 관리하기가 더 어려운, 더 복잡한 흐름을 의미한다. 기계 사용자는 즉각적인 검증이 필요해서 별도의 검증 서버와 서비스 트랙을 찾아 나설 수 있다. JWT이 경우 서비스는 사용자에게 모든 액세스 컨텍스트가 저장된 유효한 JWT가 있는지 여부만 알면 된다. 검증을 위해 별도의 프로세스를 실행할 필요가 없다. 

세 번째 방법은 클라이언트 자격 증명이다. 자격 증명은 클라이언트 ID 및 비밀 번호와 같이 애플리케이션에서 제공하는 식별 정보 모음으로, 애플리케이션을 인증하고 리소스 서버에 대한 액세스를 승인하는 데 사용된다. 클라이언트 자격 증명은 JWT를 포함하는 경우가 많고, 두 가지의 식별 정보를 요구하므로 더 안전하다는 장점이 있다. 클라이언트 자격 증명은 사용자 친화성이 낮을 수 있지만 사용자가 인간이 아니므로 문제는 되지 않는다. 

클라이언트 자격 증명을 사용하는 경우 장애를 빠르게 완화하고 병목 현상을 줄이도록 시스템을 신중하게 설계해야 한다. 구글이나 오스(OAuth)와 같은 다른 분산 시스템, 또는 서드 파티 클라우드 인증서나 토큰 기관에 의존하는 경우 이는 특히 어려울 수 있다. 이 시나리오에서 기업은 직접 생성하거나 제어하지 않는 JWT에 의존할 수 있다. 

클라이언트 자격 증명과 액세스 제어의 중간 지대는 상호 TLS(mTLS)다. mTLS는 네트워크의 각 종단에 있는 당사자가 올바른 개인 키를 갖고 있는지 여부를 검사하는 방법으로 본인이 맞는지 확인한다. 이를 통해 핸드셰이크 지점에서 부가적인 신뢰 검증 메커니즘 계층이 형성된다. 일부 서비스 메시, 역방향 프록시 및 API 게이트웨이는 기본적으로 mTLS를 적용하지만 전체 인프라 스택에 걸쳐 mTLS를 동기화하기 위해서는 제대로 된 시스템 설계와 신중한 생각이 필요하다. 
 

더 중요해진 M2M 관리 전략

서비스와 마이크로서비스의 수가 계속 증가하고 API를 기반으로 설계되는 애플리케이션이 늘어나면서 M2M 상호작용을 위한 강력한 사용자 관리 전략과 방식의 개발이 갖는 중요성도 더 커졌다. 이는 다음을 의미한다. 
 

• 사용자 관리 스택의 모든 요소와 모든 서비스의 워크플로우 맵을 생성한다. 
• 기계 사용자가 액세스할 가능성이 높은 서비스를 파악해서 비즈니스 및 보안 위험 측면에서 측정된 중요도에 따라 순위를 정한다. 
• 어느 M2M 사용자 서비스에 어떤 유형의 인증이 필요한지를 분석하고 결정한다. 
• 인간과 M2M의 모든 사용자 관리 요구사항을 충족하는 통합 사용자 관리 스택을 구축한다. 

정리하면, 기계도 사용자라는 사실을 유념해야 한다. 기계가 사용하는 서비스의 가용성과 빠른 속도, 확장성, 보안을 보장하기 위해서는 기계도 사용자와 똑같이 다뤄야 한다. 
editor@itworld.co.kr