2024-03-29 19:10 (금)
[보안칼럼] Zero Trust 구현하기
상태바
[보안칼럼] Zero Trust 구현하기
  • 길민권 기자
  • 승인 2021.09.17 15:48
이 기사를 공유합니다

다양한 경로에서 제로 트러스트를 소개할 때 가장 많이 듣는 이야기는 "아무도 믿지 마라"이렇게 표현하고 있다. 사실 난 이 표현을 마음에 들지 않는다. 왜냐면 이것은 '사용자'만을 한정하고 있기 때문이다. 2010년도에 포레스터에서 제로트러스트를 소개되었을 때는 네트워크 위주였다. 즉 '신뢰하는 네트워크'와 '신뢰하지 않는 네트워크'라는 가정에서 출발을 이제는 하지 말고, 암묵적으로 신뢰하는 네트워크는 없다고 가정하자는 것이다. 더 나아가 포레스터는 Zero Trust eXtended를 발표하여 주체의 범위를 더욱 확대해 나갔다. 그러므로 이제는 사용자만이 아닌 것이다. 그래서 그것보다는 아래의 영문 표현을 더욱 좋아한다.

"Never Trust, Always Verify"

위의 문장도 추상적인 단어로 표현되어 있어 아직은 수평선 넘어 있는 것 같다. 그러나 제로트러스트의 몇 가지 원칙을 이해하고 이 원칙을 구현해 나간다면 그렇게 어렵지는 않을 것이다.

​제로트러스트는 자원 보호에 중점을 둔 새로운 접근법이며, 암묵적으로 신뢰를 부여하는 것이 않고 지속적으로 평가해야 한다는 것이다. 제로트러스트 아키텍처는 엔터프라이즈 자원 및 데이터 보안에 대한 엔드 투 엔드(end to end) 접근 방식이고 이것은 아이덴티티(identity)를 중심으로 구현하는데, 이때 가장 중요한 부분이 최소한의 권한(least previlege)으로 자원 접근에 제한을 두어야 한다는 것이다. 사실 정보 보안을 하게 되면 최소한의 권한을 주어야 한다는 것은 다 인지하고 있으나 실제 현실에서는 적용하기 어려운 것이 사실이다. 접속이 안되거나 하면 IT 부서에 접근 권한을 넣어 달라고 요청은 하나, 그 접근 권한으로 사용한 이후에 그 권한이 더 이상 필요 없음에도 부여된 권한을 제거해 달라고 하는 경우는 거의 없다고 한다. 결과적으로 과도하게 초과된 권한이 주어져 측면 이동이라는 것이 가능하고 그 결과 측면 이동(lateral movement)에 대한 제한 이슈가 점점 중요하게 되었다. 이제까지 경계선 보안의 실패 요인으로는 일단 한번 경계선 안쪽에 들어오게 된 경우는 아무런 제약 없이 활동할 수 있었기에 보안 사고가 발생했다는 것이다.

이전에 언급했듯이 이제는 내외부의 의미를 부여하지 않고 사용자의 identity와 context(번역하기 참 어려운 단어이지만, 컨텍스트란 일반적으로 그와 연관된 여러 가지 상황을 의미한다. 보안에서는 정책을 구현할 때 OS 버전, 접속 시간, 근무형태 등의 다양한 조건을 의미한다)에 따라 사용자를 인증하고 그 후 해당 사용자에게 부여된 권한을 최소한으로 제한을 두어 end to end로 micro-segmentation으로 구현하게 되면 결과적으로 측면 이동을 제한할 수 있게 된다. 여기서의 identity+context 두 가지를 확인하고 지속적으로 평가를 해서 정책에 따라 접속을 차단하거나 허용해야 한다는 것이다.

출처=타이거CNS 블로그
출처=타이거CNS 블로그

NIST에서 제로트러스트에 구현에 대한 문서에 보면 위 그림처럼 설명하고 있다. 많은 내용이 포함되어 있는 것 같지만, 사실 간단하다. subject는 자원을 이용하려는 주체가 되는 것이고, subject는 PEP(policy enforcement point)에 의해 부여받은 권한에 따라 enterprise resource에 접속하게 되는 것이다. 이렇게 권한이 부여되기 이전에 먼저 subject는 PDP(Policy Decision Point)에서 identity를 확인(인증) 받고, identity와 context에 따라 해당 subject에 최소한의 권한만 부여하고 이것을 PEP가 집행해 주는 형태이다. NIST에서 설명하는 구현 방법이 가장 기본적인 제로 트러스트 아키텍처의 구현의 예이다. 다른 참고 자료 등에도 용어만 조금씩 다를 뿐 거의 동일한 형태를 가지고 있다.

포레스터에서는 제로트러스트를 소개하면서 벤더의 역량을 평가했다. 즉 보안 벤더는 얼마나 제로트러스트 구현을 위해 비전은 무엇인지, 얼마나 구현할 수 있는지 등등의 내용으로 벤더 역량을 평가했다. 도입하는 기업의 입장에서는 한 곳의 벤더만 선택하게 되면 해당 벤더에 종속되는 문제가 발생하므로 한 곳의 벤더로만 제로트러스트 전략을 구현할 파트너로 선정하는데 우려하겠지만, 사실 그 보고서에 나열되어 있는 회사의 제로트러스트 솔루션은 그리 많지 않으므로 솔루션별로 제로트러스트의 기본 원칙을 기반으로 얼마나 잘 만들어졌는지 확인하고, 또한 기존 시스템 또는 향후 도입될 제로트러스트 솔루션과 연계를 위한 방안(예를 들면 API)을 얼마나 지원하는지 고려하여야 한다.

자 그러면 제로트러스트에 대한 이해도 하였고 기술적인 것도 어느 정도 이해되었다. 자 다시 한번 명심하자, 단기간에 이제까지 해왔던 것을 바꿀 수는 없다. 우선순위를 두고 진행해 나가는 것이 중요하다.

"Zero Trust is long journey"

그럼 무엇을 먼저 해야 할까? NIST의 문서에서도 나와 있지만 사실 가장 중요한 것은 이제 identity이다. 예전에 클라우드의 개념이 소개되었을 때 어느 벤더에서 했던 말이 생각이 난다. 앞으로의 미래는 모두 사람을 따라다닐 것이다. 그럼 그 사람을 인증해 주는 것이 필요하다. 우리는 IT 기술에서 LDAP(Lightweight Directory Directory Access Protocol)을 사용한다. 한때 RDB를 사용하여 사용자의 정보를 저장하고 쓰는 경우도 있었으나, 글로벌하게는 LDAP을 주로 사용한다. 디렉토리 서비스라는 게 우리가 백화점이나 이런 곳에 가면 몇 층에 무엇이 있는지 층별 안내도가 있는데, 이것과 같다. 그런데 이것이 많은 데이터를 저장하고 빨리 서비스로 제공해야 하기 때문에 LDAP을 사용한다. Microsoft 사의 Active Directory도 MS 사의 디렉토리 서비스가 AD인 것이다.

과거에는 보안솔루션마다. 계정관리를 포함하고 있었다. 그 결과 기업 내에 사용하는 애플리케이션이 많아지면 더더욱 본인의 계정이 개별 애플리케이션에 저장되어 있어 복잡성이 증가했다. 즉 기억해야 할 ID가 많았고 패스워드가 많았다. 또한 애플리케이션마다 계정 또는 패스워드를 생성하는 규칙이 달라 더욱 복잡성을 증대했다. LDAP을 사용하게 되면 이런 문제를 제거해 준다. LDAP 서비스에 계정/패스워드를 저장하고 애플리케이션을 사용할 때 LDAP을 이용하여 사용자 인증을 처리하면 그만큼 관리가 쉬워지게 된다.

그런데 이 디렉토리 서비스에는 단순히 계정과 패스워드만 저장하지 않고, 계정과 관련된 다양한 정보를 저장할 수 있다. 부서, 직급, 입사일, 생일, 전화번호, 정직원/계약직, 위치 등등 아주 다양한 정보를 저장하고 이 저장된 정보를 LDAP을 써서 연동할 때 활용할 수 있다. 어느 IT 부서에서 가장 높은 등급의 긴급 처리 사항은 계정 관련이라고 한다. 즉 퇴사자가 발생하면 해당 계정을 disable 시킨다. 그러면 그 계정을 사용하던 모든 애플리케이션(이메일, 파일 서버 등등)은 접근할 수가 없게 되는 것이다. 애플리케이션에 따라서는 OU(Organization Unit:부서) 등에 따라 정책을 적용할 수 있다. 그러므로 기존에 재무부서에 마케팅 부서로 옮겼다면, 재무부서 OU에 부여되었던 권한은 제거되고 마케팅 부서 OU의 권한이 부여되는 것이다.

Directory서비스는 사용자 인증에 계정과 패스워드 조합이 일반적이다. 그러나 사용자는 습관적으로 본인이 자주 사용하는 패스워드를 사용하고, 또한 패스워드를 생성할 때 본인과 연관된 내용으로 생성하는 예가 많으므로 단순하게 사용자의 인증(authentication)이 ID+PWD의 조합으로 끝내지 않고, 다른 다양한 인증 방안을 함께 고려하여야 한다. OTP도 어렵지 않게 적용할 수 있고 많은 사용자가 이해하고 있으므로 이러한 다양한 추가 인증 방법도 함께 고려하자. 또한 이 사용자 Identity 관리는 지속적으로 관리되어야 한다는 것도 잊지 말자.

Forrester Zero Trust Maturity Phases

[글. 타이거CNS / 타이거CNS 블로그 / 문의. h9430@tigercns.com]

★정보보안 대표 미디어 데일리시큐!★

■ 보안 사건사고 제보 하기

▷ 이메일 : mkgil@dailysecu.com

▷ 제보 내용 : 보안 관련 어떤 내용이든 제보를 기다립니다!

▷ 광고문의 : jywoo@dailysecu.com

★정보보안 대표 미디어 데일리시큐 / Dailysecu, Korea's leading security media!★