|
|
|
|
웹 보안에 대한 위협과 대처방안 |
| Tech Guide-웹 보안에 대한 위협과 대처방안 |
 |
2005년 06월 27일 00:00:00 |
|
 |
|
|
안전한 웹 서비스 운영, 단계별 실천 필수
웹 서버·웹 애플리케이션 등 조화 이뤄야 … 시간·비용·인력 등 지원 필요
연·재·순·서
1. 웹 애플리케이션 보안의 현 주소
2. 웹 보안 게이트웨이의 기능
3. 향후 웹 애플리케이션 보안 시장 전망(이번호)
여성구
안철수연구소 컨설팅서비스사업부 컨설턴트
barami@ahnlab.com
이제까지 웹 애플리케이션의 보안 현실, 보안 장비, 그리고 웹 해킹 주요 기법 등을 살펴보았다. 이번 호에서는 말도 많고 탈도 많은 웹 서비스를 보다 안전하게 구성하고 운영하는 방안에 대해서 알아보자. <편집자>
이미 충분히 웹 서비스로 인해서 발생할 수 있는 보안 사고의 위험은 인지했으리라고 생각한다. 하지만 ‘웹 서비스에 대한 보안’의 중요성을 다시 한번 상기한다는 의미에서 KrCERT(www.krcert.or.kr)의 4월 해킹 통계를 살펴보도록 하자.
‘홈페이지 변조’가 2004년 총 4천812건이었던 것과 비교하여 2005년 4월까지의 합계가 1만294건임을 알 수 있다. 이는 최근 큰 문제가 되었던 phpBB와 제로보드(Zero-board)와 같이 국내에서 널리 사용되는 웹 애플리케이션의 취약점을 발표되고 이를 이용한 웜이 등장함으로 인해 1월 홈페이지 변조가 엄청나게 증가했음을 알 수 있다. 지난 호에서도 언급했지만 앞으로 산티(SANTY) 웜과 같이 강력한 파급 효과를 가져오는 웹 서비스 관련 웜의 등장은 예견돼 있다.
<그림 2>는 KrCERT에서 발표한 해킹사고 처리 현황이다. 홈페이지 변조라는 것은 웹 서비스 해킹의 한 가지 부산물에 지나지 않는다. 따라서 우리는 전체 보안 사고에 주목해야 한다. 일반 해킹에서부터 모든 보안 위험 요소가 안전한 웹 서비스를 방해하는 요소가 되는 것이다. 안전한 웹 서비스를 운영하기 위해서 보안관리자 또는 시스템/네트워크 담당자가 할 수 있는 일은 크게 다음과 같다.
· 안전한 네트워크 환경 구축
· 운영체제 보안
· 웹 컴포넌트 보안
· 웹 애플리케이션 보안
한마디로 웹 서비스를 안전하게 운영하기 위해서 고려해야 되는 것이 단순히 웹 서비스를 제공하는 웹 컴포넌트 또는 웹 애플리케이션에 국한되는 것이 아니라 통합 보안을 이뤄야 한다는 것이다. 이러한 통합 보안을 구성함에 있어서 다행스러운 점은 네트워크 환경이나 운영체제의 경우 이전 시스템 보안의 강화와 더불어 많은 부분이 개선돼 있다는 것이다. 따라서 전체 보안 요소를 모두 고려하면서 그 핵심 영역인 웹 컴포넌트와 웹 애플리케이션에 더 많은 집중을 해야 한다. 그러면 이제부터 본격적으로 안전한 네트워크 환경 구축을 시작으로 본격적인 얘기를 시작해보자.
안전한 네트워크 환경 구축
안전한 네트워크 환경 구축이란 웹 서비스를 운영함으로 인해서 발생되는 위험을 줄일 수 있는 환경으로써 침해사고의 발생 가능성을 최소화하고 침해 발생시 그 피해를 최소화할 수 있는 환경을 마련하는 것을 말한다. 현재 대부분의 네트워크는 <그림 3>과 같이 구성돼 있다고 가정해 보고 그 위험을 알아보자.
일반적인 네트워크 구성에 대해서 살펴보자면 방화벽을 기준으로 내부와 외부 네트워크 영역으로 구분되며, 대부분의 방화벽은 외부에서 내부로 접근할 수 있는 포트를 제한하고 있다. 따라서 인터넷을 통해서 극히 제한된 사용자만이 25번 포트로 접근할 수 있을 것이고 80번 포트를 통해서는 누구나가 내부 네트워크에 존재하는 웹 서버에 접근할 수 있을 것이다. 또한 일반적으로 DMZ에는 웹 서버를 비롯한 애플리케이션 서버, DB 서버, 메일 서버 등이 존재하게 된다. 내부 사용자는 DMZ에 존재하는 다양한 서버에 접근할 수 있으며, 외부로 자유롭게 나갈 수 있을 것이다. 이러한 것은 DMZ에 존재하는 다양한 서버 역시 동일하다. 그러면 이제 위험에 대해 살펴보자.
<그림 4>와 같이 외부의 해커는 웹 서버, 웹 애플리케이션 서버, DB 서버 등을 공격하여 DMZ를 장악할 수 있으며, 이렇게 DMZ를 장악하게 되면 공격자는 내부 사용자도 공격할 수 있다. 또한 침해사고라는 것은 외부에서 해커에 의해서만 일어나는 것은 아니다. 내부 사용자에 의한 침해사고에 웹 서비스는 전혀 보호받지 못하고 있는 것이 일반적이다.
안전하게 웹 서비스 제공 네트워크를 구축하기 위해서 첫 번째 웹 서비스의 트래픽을 감시 또는 차단할 수 있는 보안 솔루션이 도입돼야 한다. 이는 현재 네트워크 트래픽이 방화벽에 의해서 불필요하거나 악의적인 요청이 차단되고 있는 환경을 생각하면 당연한 것이라고 할 수 있다.
방화벽과 유사한 기능이 현재 애플리케이션 레벨에서 필요하다. 간혹 방화벽을 도입했는데 다시 이와 비슷한 솔루션을 도입해야 한다고 생각할 수 있으나 이는 엄밀히 다른 것이라고 할 수 있다. 보안이란 흐름을 따라서 흘러가는 나룻배와 유사하다고 생각한다면 추세에 맞는 해결책을 적용하는 것은 당연한 것이다. 이는 끊임없이 이뤄져야 하며, 이를 비용 낭비라고 생각하면 잘못된 것이다.
두 번째로는 DMZ에서 일반 서버와 웹 서비스 제공 서버의 분리가 필요하다. 현재 다른 어떠한 서버보다 웹 서비스는 알려지지 않은 보안 위협에 노출돼 있으며 알려진 보안 위협에도 준비 되지 않은 상태로 외부에 열려있는 서비스다. 보안의 신뢰성이 보장받지 못했다고 한 순간에 웹 서비스를 차단시키거나 없애버릴 수 있는 수준을 이미 넘어서서 기업은 취약한 사실을 알면서도 이를 운영하고 있는 것이 추세이다. 따라서 보안이 고려되지 않아 취약한 웹 서비스를 다른 서버들과 격리시킴으로써 침해가 발생했을 때의 피해를 최소화 할 수 있다. 웹 서비스 제공 서버를 중요한 서버와 동일한 네트워크 영역에 두는 것은 극히 위험한 일이다.
세 번째로 웹 서버 측에서 외부로 나가는 트래픽의 제한이 이뤄져야 한다. 해커들은 웹 서버 또는 웹 애플리케이션을 장악한 다음 작업의 편리성을 위해 ‘Reverse Shell’이라고 해서 공격 대상의 ‘xterm’과 같은 터미널을 자신의 PC로 가져온다. 이렇게 될 경우 공격자는 본격적으로 동일한 네트워크에 있는 취약한 서버들은 장악해 나갈 수 있다.
위의 세 가지 조건을 만족하는 가상 네트워크 구조는 <그림 5>와 같다. 웹 보안 솔루션이 웹 서비스 앞에서 웹 서비스로 가는 모든 트래픽을 검증한 후에 통과시키고 있으며, 웹 서비스 망과 일반 서버가 구분돼 있기 때문에 침해 사고로 인한 피해를 최소화할 수 있다. 웹 서비스 영역에서 외부로 접속 요청하는 트래픽을 제한함으로써 웹 서버를 장악한 후에 이를 경유지로 활용하여 외부를 공격하는 것을 차단할 수 있으며, 내부에 존재하는 타 서버로의 침해도 최소화할 수 있다.
운영체제 보안
네트워크가 안전하게 구성됐다면 이제 웹 서버, 웹 애플리케이션 서버 그리고 DB 서버에서 그 바탕이 되는 운영체제를 튼튼하게 할 필요가 있다. 운영체제 보안은 아주 오랜 기간 강조가 돼 와 어느 정도의 안정성은 갖추고 있으므로 간략하게만 알아보자.
첫 번째, 독립된 환경에서 운영체제를 설치해야 한다. KrCERT에서 실시한 실험에서는 MS 윈도 XP SP1과 MS 윈도 2000 SP4 2개군으로 분류하여 60회 실험을 했을 때 인터넷 망에 접속해있는 시스템은 약 60%가 10분 이내에 웜에 의해서 감염이 됐으며, 약 90%의 시스템이 30분 이내에 감염이 되는 것으로 밝혀졌다. 따라서 중요한 시스템의 경우 반드시 네트워크에 연결하지 않은 상태에서 운영체제를 설치하고 보안 패치를 적용한 후에 네트워크 망에 접속해야 한다.
두 번째, 접근 권한을 부여한다. MS 윈도의 경우 NTFS 파일 시스템을 이용하여 시스템 내의 파일이나 디렉토리에 대해서 반드시 접근 권한은 부여할 수 있도록 해야 하며, 중요한 파일이나 디렉토리의 경우 일반 사용자 또는 불필요한 사용자에 의한 접근을 차단해야 한다. 유닉스의 경우에도 반드시 중요한 파일에 대한 열람 또는 실행권한을 점검 또는 별도 설정하여 불필요한 접근으로 인해서 발생하는 정보의 노출을 막아야 한다.
세 번째, 계정 관리를 실시한다. 처음 시스템을 설치하고 나면 불필요한 계정들이 존재한다. 따라서 이러한 불필요한 계정을 삭제 또는 중지 시킴으로써 해커의 내부 접근을 막을 수 있는 좋은 대비책이 된다. 기본 비밀번호 또는 쉽게 추측 가능한 비밀번호를 사용하는 경우 변경하는 것이 필요하며 추후 정해진 비밀번호 정책에 따라서 변경하도록 설정해둬야 한다.
네 번째, 감사 정책 설정한다. 감사 정책의 결과인 로그는 침해사고가 발생했을 때 어떤 피해가 어떻게 발생했으며 그 경과가 어떻게 진행되었는지를 알 수 있는 유일한 흔적이며, 범인을 잡아 낼 수 있는 유일한 단서다. 따라서 평소에 철저한 감사 정책을 통해서 시스템의 침해의 범인 및 피해 범위를 파악할 수 있도록 해야 한다.
다섯 번째, 불필요한 서비스를 제거한다. 이 역시 운영체제를 처음 설치하게 되면 사용하지 않는 서비스까지 기본적으로 생성됨으로 인해서 각종 보안 사고에 노출되게 되는 것이다. 따라서 해당 서버의 목적에 맞게끔 최적화 설정을 통해서 불필요한 서비스를 제거하도록 한다.
여섯 번째, 마지막으로 시스템을 운영하면서 발표되는 각종 보안 패치를 적용한다. 패치라는 것을 적용한다는 것이 실 운영 시스템에서는 쉽지 않은 일이다. 실 운영 환경에 영향을 준다면 빠른 정보 수집 및 해결 방안 모색을 통해서 이를 해결해야 한다. 일반적으로 시스템의 운영 문제를 이유로 패치 적용을 꺼리는 측면이 많지만, 일반적인 패치는 추후에 하더라도 보안 패치는 바로 적용해야 보안 사고를 막을 수 있다.
웹 컴포넌트 보안
웹 서버와 웹 애플리케이션, DB 서버는 운영체제와 달리 보안이 취약한 것이 현실이다. 운영 현실을 살펴보자면 다음과 같다. 웹 서버 한 대에 다양한 호스트가 가상 호스트의 형태로 운영이 되며, 너무나 많은 서비스가 제공되고 있다. 또한 운영 중인 웹 애플리케이션에 대한 수명 관리가 이뤄지지 않고 있기 때문에 웹 서버 및 웹 애플리케이션 서버에는 폐기되어야 하는 웹 애플리케이션이 그대로 방치되고 있다.
서버 관리자는 해당 애플리케이션의 존재 유무 또는 폐기의 적정성에 대한 판단을 할 수 없기 때문에 이는 다음의 관리자에게 인수인계 할 때도 그대로 인계가 된다. 또한 현재 운영 중인 웹 애플리케이션이 ASP, JSP, PHP 등과 같은 개발 언어의 특정 버전에 특화되어 있는 경우라면 해당 웹 애플리케이션을 수정하거나 새롭게 개발하기 전까지는 운영 서버의 버전이 취약하다는 사실을 알고서도 전혀 손 댈 수 없는 환경이 된다. 또한 DB 서버 역시 중요한 데이터들이 많이 있기 때문에 패치가 나왔다고 해서 무작정 실시할 수도 없다.
이와 같은 환경적인 요소 외에도 서버 관리자의 실수 또는 안일함으로 인해서 보안이 취약한 샘플 파일 또는 백업, 임시 파일들이 방치되거나 기본 설정을 그대로 사용함으로 인해서 공격자에게 중요한 정보를 노출하는 사태가 빈번하게 일어난다.
이 같은 환경적인 요소와 관리자의 실수를 방지하기 위해서는 우선 새로운 서버를 설치하고 운영하는 데 필요한 정형화된 설치·운영 절차가 필요하다(상대적으로 운영체제 영역의 경우 이러한 절차가 잘되어 있다).
그 다음으로는 웹 서버, 웹 애플리케이션 서버, DB 서버 등을 설치한 후에 기본적으로 제공되는 모든 샘플파일을 삭제 또는 이동시키도록 한다. 샘플파일로 인해서 발생하는 보안 사고는 작게는 정보 노출에서부터 시스템 권한 노출까지 다양하게 발생할 수 있다. 벤더에서 샘플파일을 제공하는 그 이유는 설치한 애플리케이션이 정상적으로 설치가 되었고 정상적으로 작동하는지를 점검해보라는 것이 가장 큰 이유라고 본다면 이를 실제 운영 환경에서 방치할 이유는 어디에도 없다.
세 번째로는 해당 환경에 맞게끔 설정 파일을 최적화해야 한다. 현재 많은 벤더들이 기본적으로 제공하는 설정에 보안적인 사항을 반영하고는 있지만 그것만으로는 부족하다. 샘플 파일 또는 기본적인 기능 구현을 위해서 활성화돼 있거나 비활성화돼 있는 설정들이 다수 존재한다. 이를 해당 서버와 애플리케이션 설정에 맞게끔 수정하는 것이 필요하다.
네 번째로는 서버에서 반환하는 에러의 처리다. 웹 애플리케이션을 실행시키면서 발생하는 오류는 크게 웹 애플리케이션을 제작할 때 개발자가 디버그를 목적으로 의도적으로 넣은 것과 서버 측에서 웹 애플리케이션이 예상 외의 작동을 했을 때 에러 메시지를 반환하는 경우가 있다. 서버 관리자는 서버 측에서 반환될 수 있는 에러 메시지를 최소화 해야 한다.
마지막으로 접근 제어를 실시해야 한다.
방화벽 또는 운영체제 차원에서 웹 애플리케이션 또는 웹 서버의 특정 디렉토리에 대해서 접근 제어를 실시하는 것은 부적합하다고 할 수 있다. 이를 구현하기에 가장 적합한 지점이 바로 웹 서버와 웹 애플리케이션이라고 할 수 있다. 예를 들어 웹 서버의 ‘/admin’이란 디렉토리에 관리자 인터페이스가 존재한다면 이는 특정 IP에서만 접근을 허용하면 된다. 이는 웹 서버에서 환경 설정을 통해서 또는 웹 애플리케이션 서버에서 환경설정에서 이를 구현할 수 있다.
웹 애플리케이션 보안
이제 가장 핵심적인 부분이라고 할 수 있으며 가장 골치덩어리인 웹 애플리케이션에 대해서 알아보자. 현재의 ‘웹 해킹’이란 것은 웹 애플리케이션을 그 주 공격대상으로 보고 있다. 이는 웹 컴포넌트 벤더들이 점점 보안을 고려해 개발을 하고 있으며, 보안 취약점이 발표되었을 때 최대한 빨리 관련 패치를 발표하는 것과 무관하지 않다. 이에 반해 웹 애플리케이션의 경우는 매우 비참하다.
현재 이미 개발되어 있는 대부분의 웹 애플리케이션은 중소 규모의 개발 업체가 개발을 한 것이 대부분이며, 개발 당시에 보안 요구사항에 필요성이 존재하지 않았기 때문에 보안을 고려하여 개발되지 않은 것들이 대부분이다. 이는 대규모의 개발 업체 역시 마찬가지다. 이러한 개발은 중소 규모 또는 프로젝트의 성격으로 일회성이 강하기 때문에 한번 개발된 웹 애플리케이션은 그 수명이 다할 때까지 수정이란 작업이 이루어지기 힘들다. 변화가 빠른 웹의 특성상 수정을 하기보다는 새롭게 개발을 의뢰하는 경우가 많은 데 이때 역시 보안이 고려되기는 힘들다. 현재 다수의 개발 업체에서 최근 문제가 되고 있는 취약점에 대비할 수 있도록 많은 노력을 기울이고는 있지만 웹 애플리케이션을 안전하게 보호하기에는 부족한 것이 사실이다.
<그림 6>의 왼쪽 그래프가 바로 가장 이상적인 웹 애플리케이션이라고 할 수 있다. 가장 이상적인 웹 애플리케이션은 보안이 고려된 상황 하에서 개발되고 검증돼 요구되는 보안 수준을 만족하는 위치에서 운영되기 시작한다. 시간이 지남에 따라서 새로운 보안 취약점이 등장하게 되고 요구되는 보안 수준은 점점 더 많아 진다. 이에 반비례해 안전하게 개발된 웹 애플리케이션의 보안 수준도 점점 하향하게 되며, 어느 정도의 시점에 오면 보안 패치 즉 소스 수정과 같은 조치가 필요하다. 이렇게 보안 패치가 이뤄진 웹 애플리케이션은 다시 보안 수준이 상향하게 되고 다시 조금씩 하향 곡선을 그리다 폐기된다.
현실적으로는 거의 불가능한 것이 위의 이상적인 웹 애플리케이션의 모습이다. 이제 그 문제점을 하나씩 짚어보기로 하자. 첫 번째 개발 단계에서는 보안을 고려한 설계를 해야 하는데 이때 최우선적으로 발생하는 문제가 바로 비용이다. 이전에는 보안을 고려하지 않고도 충족시킬 수 있었던 요구사항이 보안이 고려하게 됨으로 인해서 발생하게 된 비용을 개발업체와 웹 애플리케이션의 의뢰 업체 모두 부담하기 싫어하기 때문에 갈등 문제가 빚어지게 되고 결국 웹 애플리케이션에서 보안 요소는 제외가 된다.
두 번째는 시간이다. 개발을 실제할 때는 충분한 시간이 주어지지 않는다. 대부분의 개발업체는 빠듯한 개발 일정으로 인해서 기본적인 기능만을 충족시키기에도 시간이 부족한 것이 현실인데 거기에 보안까지 고려하면 개발 기간은 길어질 수밖에 없지만 이러한 사정이 용인되지 않는 것이 현실이다. 마지막으로 기술을 들 수 있다. 개발 업체는 개발 인력을 다수 보유하고 있을 뿐 보안 전문가를 보유하고 있지 못하다. 따라서 보안을 고려해 개발했다고 하더라도 현실적으로 제대로 고려된 것인지에 대한 검증인지 실시할 기술력이 없다.
다음으로 운영 단계를 살펴보면 웹 애플리케이션의 보안 수준이 적정 수준까지 떨어진다면 보안패치 즉, 소스 수정이 필요한데 대부분의 웹 애플리케이션을 외부 업체에게 의뢰를 했기 때문에 실제 운영하는 업체 측에서는 이를 수정할 능력이 없는 것이 현실이다. 따라서 개발할 때와 동일한 비용, 기간이 소요되는 이러한 패치 작업을 그냥 무시할 수밖에 없다. 또한 운영중인 상황에서 모의해킹이나 다양한 보안 점검을 통해서 보안 문제점이 도출됐다면 문제는 더욱 커지게 된다. 소스를 수정하는 데 소요되는 기간 동안 웹 서비스를 중단시킬 수가 없기 때문이다.
마지막으로 폐기 단계에서는 웹 컴포넌트 단계에서 말한 것과 같이 처음 개발되었을 때부터 적절한 수명 관리를 실시하지 않았기 때문에 웹 애플리케이션이 수명을 다 했음에도 불구하고 웹 서버에 그대로 방치되고 그때부터 허공에 붕 뜬 유령 애플리케이션이 되고 만다.
그러면 이러한 웹 애플리케이션의 문제점을 해결할 수 있는 방법은 무엇일까? 아쉽게도 현재 가능한 대응방안은 웹 보안 솔루션(Web Application Security Gateway)의 도입 밖에 없다. 왜냐하면 웹 서비스 보안에 대한 필요성을 가지고 있는 대부분의 기업이 현재 웹 서비스를 운영하고 있으며, 비록 웹 서비스가 취약하다 하더라도 이를 수정할 환경이 되지 않는 기업이 대부분이기 때문이다.
운영 환경에서 웹 보안 솔루션을 도입하게 되면 <그림 7>과 같이 비록 웹 애플리케이션이 취약하다고 하더라도 이를 보완해줄 수 있다. 외부에서 오는 모든 요청들을 웹 보안 솔루션이 검증하고 차단하기 때문에 악의적인 요청이 실제로 취약한 웹 애플리케이션에 전달되지 않는다. 또한 장점으로는 소스 수정과 달리 오랜 시간이 소요되지 않는다는 점이 있다. 하지만 웹 보안 솔루션을 도입했더라도 소스 수정 능력이 있다면 이를 수정하는 것이 바람직하다. 방화벽 내부에 대부분의 서버들이 서비스 관리 및 보안 패치를 실시하지 않아서 해킹 당하는 것이 현실인 것을 감안한다면, 웹 애플리케이션 역시 자체적으로 보안성을 갖추어 가는 것이 바람직하다.
그러면 앞으로 개발되는 웹 애플리케이션 역시 웹 보안 솔루션만 있으면 되는 것일까? ‘그렇다’라고 말을 할 수도 있지만 그렇게 하기 이전에 아직 개발 단계에서의 개선의 여지가 남아 있다. 개발 단계에서 보안 요소를 고려해 개발을 하게 되면 굳이 웹 보안 솔루션에 기대 운영될 필요는 없다. 아래 <그림 8>은 보안을 고려해 웹 애플리케이션을 개발하는 단계를 설명한 그림이다. 분석, 디자인, 개발, 배치, 운영 단계에서 각각 보안성을 가미하고 검증함으로써 보다 보안성이 향상된 웹 애플리케이션을 개발할 수 있다. 하지만 이렇게 개발된 환경에서도 웹 보안 솔루션을 도입한다면, 아직 알려지지 않은 보안 위협에 대해서도 방어할 수 있다는 이점이 있다.
안전한 웹 서비스를 운영하기 위해서는 지금까지 언급한 네트워크 구성, 운영체제, 웹 서비스를 제공하는 서버, 마지막으로 웹 애플리케이션 이들 네 가지 요소가 반드시 허점이 없어야 한다. 어느 것 하나라도 허술하거나 공격자에게 공격에 필요한 충분한 요소를 제공한다면 전체 네트워크가 무너지고 마는 것이 현실이다.
3개월 동안 웹 보안 솔루션에 대한 소개와 웹 취약점, 그리고 그 대응방안에 대해서 알아봤다. 너무 위험하다라고 위험만 부각시킨 것 아니냐라고 생각할 수 있다. 하지만 이제까지 고객사를 대상으로 모의해킹을 실시하면서 쌓인 경험으로는 단순히 위험하다고 허풍을 떠는 것이 전혀 아니라고 생각을 한다. 고객사의 모든 문이 대부분 웹을 통해서 열리기 때문이다. 최근 정통부와 KISA에서 홈페이지 해킹사고 예방을 위해서 ‘홈페이지 개발 보안 가이드’를 발표했다(www.kisa. or.kr/news/2005/ announce_20050427_submit.html).
안전한 웹 서비스 개발에 관심이 있는 독자는 이 가이드를 참고하기 바란다. |
|
|
|
|
|
|
|
|
|
| ⓒ 데이터넷(http://t564.ndsoftnews.com) 무단전재 및 재배포금지 | 저작권문의 |
|
|
|
|
|
|
| |
| 가장 많이 본 기사 |
|
|
 |
|
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
