SASE 도입 및 K-ISMS 고려사항

15 min readAug 30, 2022

미디엄에 첫 글을 쓰기 전, 걱정과 두려움이 많았습니다.

하지만 이 글을 공개하면 다양한 분들의 피드백을 받을 수 있고, 더욱 성장할 수 있을 것이라는 생각에 이 글을 쓰게 되었습니다. 내용이 부족하다면 언제든지 피드백 부탁드립니다.

이 글을 읽어주시는 모든 분들께 감사드립니다!

0. BackGround

SASE 도입을 검토하게 된 계기는 이 글을 작성하기 1년 전 부족한 사내 보안 정책 상 사내가 아닌, 사외에서는 그 어떠한 경우에도 업무 리소스를 확인할 수 없었습니다. 하지만, 2021년 코로나 19 감염자의 폭발적인 증가와 국가에서 보건 정책 4단계 격리 방역 지침을 준수하기 위한 수단이 필요로 했습니다. 즉 더 이상의 업무 공간을 사내로 한정 짓는 것이 아닌 사외에서 보안 사항이 위배되지 않는 안전한 근무를 수행할 수 있도록 환경 구성이 필요성이 대두되었습니다. 원격 근무 환경을 구성하기 위해 On-premises 환경에서는 VPN을 활용하는 방식과, 처음으로 SASE(Secure Access Service Edge)를 활용하는 방식 중에 고민했으며, 이때 당시 2가지 방법에 대해 고민하던 중 2021년 VPN으로 인한 보안 사고가 자주 발생하고 있던 상황과 업무의 유연성과 클라우드 환경을 사용하는 환경에 보다 적합한 SASE 프레임워크를 도입하기로 결정했습니다. 위 글은 SASE를 도입을 준비하면서 검토한 내용을 공유하기 위해 작성하게 되었습니다.

1. SASE의 First Step : ZTNA

최근 클라우드 환경의 변화와 기업에서 Google WorkSpace(이하 GWS), Slack, Zendesk, Dropbox, Microsoft Office와 같은 서비스형 소프트웨어(이하 SaaS)의 사용이 증가함에 따라 클라우드 환경에 데이터가 저장되기 시작하며, 기존 방화벽을 기준으로 설계된 레거시(경계 보안) 환경의 경계를 구분하는 것이 모호해지기 시작했습니다. SASE의 핵심은 기업 내 리소스(User, Device, Application)를 Identity 기반으로 액세스하며, 레거시 환경의 가장 큰 차이점은 사용자의 위치와 관계없이, 사용자 또는 디바이스를 신뢰하지 않고, 항상 검증을 수행하며, 동일 수준의 보안을 적용하는 것입니다. 하지만 기존 조직에 구성된 보안 아키텍처는 레거시(경계 보안) 환경에 맞게 설계되어 있으며, 이는 사용자가 사외에 있으면 사용자와 디바이스를 검증할 수 없으며, 동일한 레벨의 보안을 적용할 수 없다는 문제가 존재합니다.

위 문제를 해결하기 위해 SASE를 구성 요건의 Zero-Trust Network Access(이하 ZTNA), SWG, FWaaS, CASB 중 Identity 기반으로 실제 인증을 수행하는 개념인 ZTNA에서 정의된 성숙도 모델을 토대로 SASE 구성을 위한 효과적인 Identity 항목을 도출하고, 도출 항목에 대해 실제 적용 방안에 관해서도 이야기하고자 합니다. 추가로 도출된 방안을 적용할 때 발생할 수 있는 보안 위협을 ISMS-P 결함 항목과 매핑하여 안내하고자 합니다. 위 글에서 사용된 ZTNA 성숙도 모델의 경우 Microsoft에서 작성된 ztna 성숙도 모델을 사용하였으며, ztna 성숙도 모델의 경우 작성한 벤더사마다 약간의 구성 요소 간의 차이는 존재하지만, 세부적인 내용은 동일합니다.

MicroSoft ZTNA 성숙도 모델의 경우 Identities, Devices, App, Infrastructure, Network, Data 총 6가지로 분류하였으나, 각 요소는 정의하는 곳에 따라 약간의 차이가 존재합니다. 실제 CISA의 경우 Identity, Device, Network/Environment, Applications Workload, Data로 총 5가지로 분류하고 있습니다.

In the case of the MicroSoft ZTNA maturity model, it is classified into six categories: Identities, Devices, App, Infrastructure, Network, and Data, but there are slight differences depending on where each element is defined. In the case of actual CISA, it is classified into five categories: Identity, Device, Network/Environment, Applications Workload, and Data. — MicroSoft에서 정의한 ZTNA 성숙도

2. ZTNA 환경 변화에 따른 ISMS 주요 결함 항목

2–1) Identities

ZTNA 환경에서 가장 중요한 요소 중 하나인 Identities는 사용자, 장비, 어플리케이션 세 가지 분야에 대한 식별을 포함하고 있으며, 우선 사용자에 대한 식별에 관해 설명하도록 하겠습니다.

MicroSoft에서 사용자에 대한 식별의 경우 기존 레거시(경계 보안)에서 사용하는 IDP(Identity Provider)를 Cloud ID와 통합하여 사용하도록 권장하고 있습니다. 하지만 자사의 경우 On-premises 환경에는 IDP가 사용되지 않으며, Cloud 환경에서 이용 중인 Application(Slack, Notion)은 Google O-Auth2로 사용되며, 일부 서비스는 별도로 계정 및 권한을 관리하고 있었으며, 이를 통합하기 위한 방법으로는 기존에 사용하는 Google로 통합, AWS에서 제공되는 IAM Identity Center를 활용하는 방법, IDP Application을 별도로 구매하여 구성하는 방법이 존재하였습니다. 위 방법 중 자사의 경우 Google를 활용하여 통합을 수행하고자 했으나, Google로 통합을 수행할 경우 기존 On-premises와 연동 시 폐쇄망 구간에 다량의 FQDN을 등록 및 Google을 IDP로 이용 시 Application 통합이 제한적이라는 점 등을 고려하여, IDP로 사용할 Third-Party 솔루션을 구축하는 것이 효과적일 것으로 판단했습니다. 저의 경우 OKTA Third-Party 를 선택했습니다.

Zscaler의 경우 OKTA와 파트너쉽으로 인해 OKTA를 별도 구매하지 않은 조직의 경우 Zscaler 연결만 수행할 수 있는 무료 계정을 제공함으로, 유료 라이센스를 필수적으로 구매해야 하는 것은 아닙니다.

2번째 디바이스 Identities에 관해 설명하도록 하겠습니다. 보통 디바이스 식별의 경우 사용자 계정에 대한 식별 시 함께 이뤄줘야 합니다. 자사의 경우 위에서 언급한 대로 처음 Google로 로그인을 수행하고, 디바이스 식별을 함께 수행하고자 했습니다. 하지만, OKTA로 사용자 식별을 수행할 경우 구글 로그인 계정으로 O-Auth 2를 사용하는 Application은 통제할 수 있으나, O-Auth 2가 아닌 경우 접근 통제를 수행할 수 없다는 문제가 있습니다. 이러한 문제를 해결하기 위해 Okta Verify Desktop App을 통해서 사용자 기기에 대한 등록을 수행했습니다.

마지막 Application의 경우 On-premises에서 사용 가능한 Application, 사내 Cloud 환경 내 모든 Workloads, 퍼블릭 클라우드 서비스(Slack, Notion 등) 총 3가지로 분류할 수 있으며, 위3 가지를 어떻게 식별하고, 통합하였는지에 대한 자세한 설명은 아래 2–3 Application에서 자세히 설명하고자 합니다.

지금까지 ZTNA를 구성하는 가장 중요한 Identities의 3가지에 관해서 설명과 자사에서 구성한 Identities에 관해서 설명했습니다. 그렇다면, 자사에서 IDaaS(Identity as-a-service의 줄임말로, SaaS솔루션을 기반으로하는 IDP 솔루션을 의미)를 도입함으로써 발생할 수 있는 K-ISMS(국내 정보보호 관리체계)의 주요 결함을 방지하기 위해 작성한 체크리스트를 함께 공유합니다.

2–2) Devices

2번째 Devices의 경우 Devices에 대한 식별과 Devices에 대한 통제 방안 2가지로 분류할 수 있습니다. Devices에 대한 식별은 Identities에 2번째 항목에 관해 확인할 수 있으며, 위 장에서는 Devices 통제 방안을 위주로 작성되었습니다. Microsoft에서 정의하는 레거시(경계 보안) ZTNA 환경에서 사용자의 장치를 식별하고, 식별된 장치에 따라 사용자의 위치와 관계없이 업무 리소스를 사용하도록 권고하고 있습니다. 기존에 On-premises 환경에서 Endpoint 보안 정책을 구성 및 배포하기 위해 구성된 정보보안 솔루션(Endpoint Protection Platform, DLP, NAC)의 경우 사외에 존재하는 Endpoint를 통제할 수 없다는 한계가 있습니다. 사용자의 위치와 관계없이 업무용 단말 기기에 동일한 보안 정책을 적용하는 방법은 SaaS 솔루션 변경, 기존 On-premises 솔루션을 사내 클라우드로 이전, Private IP로 설정된 보안 솔루션을 Public IP로 변경 후 Source 대역을 모두 허용하는 방안이 존재합니다. 위 방법 중 기존 Private IP로 운영 중인 보안 솔루션을 Public IP로 변경할 경우 ISMS 내 “2.6 접근통제, 2.10.2 클라우드 보안, 2.10.3 공개 서버 보안” 등에서 결함이 발생할 수 있다고 판단하였으며, On-premises에서 AWS로 이관의 경우 벤더사에서 클라우드 환경에 서비스 시 유지보수 및 레퍼런스가 부족하였습니다. 최종적으로 기존에 사용 중인 솔루션을 점진적으로 폐쇄하고, SaaS 형태의 별도 솔루션을 통해 Endpoint를 통제하는 방법을 선택했습니다. 이에 따른 Endpoint의 통제 항목 일부를 공유드립니다.

화면 보호기 설정
장치 비밀번호 복잡성
기기 PW 변경 주기
필수 SW 설치 여부
엔드포인트 패치 관리
등

2–3) Applications

Application의 경우 위에서 언급한 대로 3가지 Application에 대한 식별을 수행해야 합니다. 또한 Microsoft에서 정의하는 ZTNA 환경의 Applications를 식별하여, 최소한의 권한을 부여하기를 권고하고 있습니다. 지금 부터 각 분류에 따른 식별 방법과 자사의 적용 방안에 관해 설명하고자 합니다.

2–3–1) On-premises

On-premises에 존재하는 Application을 수행하기 위한 방법에 대해 가장 많은 고민이 있었습니다. 사용자의 위치와 관계없이 개인정보를 취급 업무를 수행할 경우 ISMS-P의 주요 항목에 결함이 발생할 수 있으며, 이는 더 나아가 심사가 취소될 수도 있습니다. 이러한 문제를 방지하기 위해 금융기관에서 사외 업무 수행 시 점검할 사항에 대해 금융보안원에서 2020년 12월에 발매한 “금융회사 재택근무 보안 안내서”를 참고하여, 통제 항목을 식별하고, 항목에 적합한 인프라 환경을 구성하고자 했습니다.

해당 보고서에 따르면, 원격 근무 시 On-premises Applications를 사용하는 방식을 외부 단말기에서 내부 업무 처리 단말에 직접 접속을 수행하는 직접 접속 방식과 외부 단말기에서 내부 업무 처리 단말을 경유하여 접속하는 간접 접속으로 분류하고 있습니다. 자사의 경우 위 2가지 방법 중 AWS VDI를 통한 간접 접속 방식을 구성하였습니다. 간접 접속 방식을 이용할 경우 다음과 같은 통제 항목을 준수하기를 권고하고 있습니다.

위에서 정의된 필수 항목은 파일 송수신 차단, 취약 프로그램 사용 금지, 기본 포트 사용 금지, 업무용 단말기 미인가 조작 금지 중 “업무용 단말기 미인가 조작”, “취약 프로그램 사용 금지” 금지 항목의 경우 정책 변경 Endpoint 통제 항목과 일치됨으로 자세한 설명 2–2) Devices에 작성된 내용으로 대체하도록 하겠습니다. “파일 송수신 차단“은 AWS WorkSpace에서 기본 설정으로 차단되어 있습니다. 하지만, 클립보드의 경우 Workspace가 동작 중인 VPC(Virtual Private Cloud) 내 Windows Server EC2에 별도 설정을 변경해야 하며, 전체 수행 방법은 다음과 같습니다.

위 과정을 모두 수행한다면, “파일 송수신” 항목을 적절하게 통제할 수 있습니다. 이로써 금융보안원에서 정의한 원격에서 사내 업무 리소스를 사용하는 방안에 대한 통제 항목을 모두 준수할 수 있습니다.

2–3–2) Cloud’s Workloads

자사의 경우 Cloud 콘솔 페이지 접속 통제를 경계 보안의 경우 Source IP를 기준으로 접근을 통제하였습니다. 하지만 ZTNA 환경의 경우 User의 위치와 관계없이 Cloud 콘솔 페이지 접속이 가능하도록 설정이 필요하며 이는 기존 Source IP 접근 통제는 사용할 수 없다는 의미입니다. 이를 위해 Zscaler 기능 중 네트워크 패킷 발송을 위해 조직 클라우드 내 구성하여, 특정 사용자(AWS 콘솔 페이지 접속이 필요한 조직 내 일부 사용자)가 특정 도메인(클라우드 도메인)을 요청할 때 패킷 발송지를 포워딩하는 기능인 Private Access 기능으로 구성하였습니다. 위 구성을 수행하며, 기존 AWS 콘솔 관리자 계정의 IAM 권한을 다음과 같이 수정하였습니다.

2–3–3) SaaS

자사의 경우 레거시 환경에서 이용 중인 SaaS는 Slack, Notion, Jira, Zendesk 등을 사용하고 있었으며, 해당 Applications는 Google O-Auth 2를 사용해 계정을 통합하여 사용하고 있었습니다. GWS(Google WorkSpace)의 경우 IP 접근 통제로 수행하여 접근통제를 구성했습니다. 하지만, 보안 솔루션의 일부 관리자 페이지와 ERP의 경우 Google 로그인을 제공하지 않거나, 로그인 시 허용 IP 기능을 제공하지 않는 Application에 대한 접근 통제 및 최소 권한 설정을 수행할 수 없는 문제점이 존재했습니다.

만약 접근 통제를 수행할 방법이 존재하지 않을 경우 2–1) Identities에서 발생한 주요 항목의 결함이 동일하게 발생할 수 있다는 문제가 있습니다. 위 문제를 해결하기 위해 사용자 계정 및 관리자 계정에 대해 OKTA Saml 연동으로 OKTA 연동 통해 접근 통제, 계정 최신화를 수행하였습니다.

3. SASE의 Second Step : SD-WAN, SWG, FWaaS

위 과정을 통해 SASE에서 가장 중요한 개념인 ZTNA의 요구사항과 이를 사내 인프라에 적용하였습니다. 지금부터는 SASE를 구성하기 위한 나머지 SWG, CASB, Fatwas에 대해 설명하고자 합니다. 위 기능 중 SWG의 경우 조직 내에서 별도로 작업을 수행하는 것이 아니라, Zscaler에서 실시간 업데이트를 수행한 Cloud를 우리가 이용하는 것으로 별도로 변경할 내용은 없습니다. SD-WAN의 경우에도, Zscaler의 인프라를 이용하는 것으로 대체할 수 있습니다.

FWaaS의 경우 기존 On-premises 내 네트워크 단에서 방화벽으로 사용 Port를 통제하던 구성에서, Endpoint에서 발생하는 네트워크 패킷이 인터넷에 도달하기 전 Zscaler에서 Port로 통신 포트를 제어하는 것으로 대체했습니다. 최종적인 인프라 구성은 다음과 같습니다.

4. 마치며

지금까지 긴 글을 모두 읽어 주셔서 감사합니다. 많은 분이 SASE 도입을 수행할 경우 ISMS-P에 대한 내용을 보다 ZTNA의 내용이 많은 것에 의문을 품을 수도 있습니다. 이것은 SASE를 구성할 때 타 기능보다 ZTNA에 따른 변화가 가장 크며, 가장 중요합니다. 나머지 SWG, CASB, FWaaS의 경우 기존에 네트워크 단에서 수행하는 것을 Endpoint 단에서 수행하는 위치의 차이에 따른 ISMS 고려해야 할 항목이 크게 변경되지 않는다고 판단하여, ZTNA의 내용에 대해 보다 상세히 작성되었습니다.

추가로 위에서 잠깐 언급했지만, MicroSoft의 ZTNA 성숙도 모델 내 모니터링에 대한 부분이 중요하다고 언급되고 있으나, 해당 글에는 모니터링과 관련된 어떠한 내용을 작성하지 않았습니다. 해당 글에 모니터링 내용을 함께 작성한다면, 글의 내용이 너무 길어질 것 같아, 추후 제가 작성한 모니터링 점검 내용에 대해 추후 정리하여 작성할 예정입니다. 그럼 지금까지 긴 글을 모두 읽어 주셔서 감사합니다.